CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52583 – ceph: fix deadlock or deadcode of misusing dget()
https://notcve.org/view.php?id=CVE-2023-52583
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ceph: corrige el punto muerto o el código muerto por uso incorrecto de dget() El orden de bloqueo es incorrecto entre denty y su padre, siempre debemos asegurarnos de que el padre obtenga el bloqueo primero. Pero dado que este código muerto nunca se usa y el directorio principal siempre será configurado por quienes llaman, simplemente eliminémoslo. • https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6 https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980 https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3 https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160 https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67 https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48630 – crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ
https://notcve.org/view.php?id=CVE-2022-48630
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running: kcapi-rng -b 67 >/dev/null There are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that. Tested on a machine with Qualcomm Amberwing processor. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qcom-rng: corrige el bucle infinito en solicitudes que no sean múltiples de WORD_SZ. El commit a la que se hace referencia en la etiqueta Fixes eliminó la 'ruptura' de la rama else en qcom_rng_read(), lo que provocó una bucle infinito siempre que 'max' no sea un múltiplo de WORD_SZ. Esto se puede reproducir, por ejemplo, ejecutando: kcapi-rng -b 67 >/dev/null Hay muchas formas de solucionar este problema sin volver a agregar el 'descanso', pero todas parecen más incómodas que simplemente volver a agregarlo, así que hazlo. • https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d https://git.kernel.org/stable/c/71a89789552b7faf3ef27969b9bc783fa0df3550 https://git.kernel.org/stable/c/8be06f62b426801dba43ddf8893952a0e •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48629 – crypto: qcom-rng - ensure buffer for generate is completely filled
https://notcve.org/view.php?id=CVE-2022-48629
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 � 32883 0.003654 254 � 33035 0.003671 255 � 33239 0.003693 Total: 9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 � 35201 0.003911 254 � 34835 0.003871 255 � 35368 0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: qcom-rng: asegúrese de que el búfer para generar esté completamente lleno. La función de generación en la estructura rng_alg espera que el búfer de destino esté completamente lleno si la función devuelve 0. qcom_rng_read() puede ejecutarse en una situación en la que el búfer está parcialmente lleno de aleatoriedad y la parte restante del búfer se pone a cero ya que qcom_rng_generate() no verifica el valor de retorno. • https://git.kernel.org/stable/c/ceec5f5b59882b871a722ca4d49b767a09a4bde9 https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47108 – drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
https://notcve.org/view.php?id=CVE-2021-47108
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf In commit 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only") a check for CEA modes was added to function mtk_hdmi_bridge_mode_valid() in order to address possible issues on MT8167; moreover, with commit c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock") another similar check was introduced. Unfortunately though, at the time of writing, MT8173 does not provide any mtk_hdmi_conf structure and this is crashing the kernel with NULL pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as soon as a HDMI cable gets plugged in. To fix this regression, add a NULL pointer check for hdmi->conf in the said function, restoring HDMI functionality and avoiding NULL pointer kernel panics. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: hdmi: realice una verificación de puntero NULL para mtk_hdmi_conf En el commit 41ca9caaae0b ("drm/mediatek: hdmi: agregue verificación solo para modos CEA") se agregó una verificación para los modos CEA funcionar mtk_hdmi_bridge_mode_valid() para solucionar posibles problemas en MT8167; Además, con el commit c91026a938c2 ("drm/mediatek: hdmi: Agregar límite opcional en el reloj máximo en modo HDMI") se introdujo otra verificación similar. Desafortunadamente, al momento de escribir este artículo, MT8173 no proporciona ninguna estructura mtk_hdmi_conf y esto bloquea el kernel con un puntero NULL al ingresar a mtk_hdmi_bridge_mode_valid(), lo que sucede tan pronto como se conecta un cable HDMI. Para solucionar esta regresión, agregue un El puntero NULL comprueba hdmi->conf en dicha función, restaurando la funcionalidad HDMI y evitando pánicos del kernel del puntero NULL. • https://git.kernel.org/stable/c/41ca9caaae0bfc959b22dbcd59d88a7107707e17 https://git.kernel.org/stable/c/71d07ebc5000b9c1d140e99e7493b0bafa954776 https://git.kernel.org/stable/c/3b8e19a0aa3933a785be9f1541afd8d398c4ec69 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47107 – NFSD: Fix READDIR buffer overflow
https://notcve.org/view.php?id=CVE-2021-47107
In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix READDIR buffer overflow If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. Also, we have no unit tests that exercise the behavior of READDIR at the lower bound of @count values. Thus this case was missed during testing. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFSD: corrige el desbordamiento del búfer READDIR Si un cliente envía un argumento de recuento READDIR que es demasiado pequeño (digamos, cero), entonces el cálculo del tamaño del búfer en las nuevas funciones auxiliares init_dirlist da como resultado un subdesbordamiento, lo que permite que las funciones de flujo XDR escriban más allá del búfer real. • https://git.kernel.org/stable/c/7f87fc2d34d475225e78b7f5c4eabb121f4282b2 https://git.kernel.org/stable/c/eabc0aab98e5218ceecd82069b0d6fdfff5ee885 https://git.kernel.org/stable/c/53b1119a6e5028b125f431a0116ba73510d82a72 https://git.kernel.org/stable/c/9e291a6a28d32545ed2fd959a8165144d1724df1 •