CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52585 – drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()
https://notcve.org/view.php?id=CVE-2023-52585
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() Return invalid error code -EINVAL for invalid block id. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige una posible desreferencia NULL en amdgpu_ras_query_error_status_helper() Devuelve un código de error no válido -EINVAL para una identificación de bloque no válida. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 error amdgpu_ras_query_error_status_helper(): anteriormente asumimos que la 'información' podría ser nula (consulte la línea 1176) A vulnerability was found in the amdgpu_ras_query_error_status_helper() function in the Linunx kernel which could lead to a possible NULL pointer dereference, causing data corruption or crashes. • https://git.kernel.org/stable/c/467139546f3fb93913de064461b1a43a212d7626 https://git.kernel.org/stable/c/0eb296233f86750102aa43b97879b8d8311f249a https://git.kernel.org/stable/c/7e6d6f27522bcd037856234b720ff607b9c4a09b https://git.kernel.org/stable/c/92cb363d16ac1e41c9764cdb513d0e89a6ff4915 https://git.kernel.org/stable/c/c364e7a34c85c2154fb2e47561965d5b5a0b69b1 https://git.kernel.org/stable/c/195a6289282e039024ad30ba66e6f94a4d0fbe49 https://git.kernel.org/stable/c/b8d55a90fd55b767c25687747e2b24abd1ef8680 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-476: NULL Pointer Dereference •
CVSS: 3.8EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52584 – spmi: mediatek: Fix UAF on device remove
https://notcve.org/view.php?id=CVE-2023-52584
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spmi: mediatek: reparar UAF en la eliminación del dispositivo. Los datos del controlador pmif que contienen los relojes se asignan junto con spmi_controller. Al eliminar el dispositivo, primero se liberará spmi_controller y luego se limpiarán los devres, incluidos los relojes. Esto lleva a UAF porque al poner los relojes se accederá a los relojes en los datos del controlador pmif, que ya están liberados junto con spmi_controller. • https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8 https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9 • CWE-416: Use After Free •
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-2024-26622 – tomoyo: fix UAF write bug in tomoyo_write_control()
https://notcve.org/view.php?id=CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tomoyo: corrige el error de escritura UAF en tomoyo_write_control() Dado que tomoyo_write_control() actualiza head->write_buf cuando se solicita write() de líneas largas, necesitamos recuperar head->write_buf después head->io_sem se mantiene. De lo contrario, las solicitudes de escritura () simultáneas pueden causar problemas de use-after-free-write y de doble liberación. • https://git.kernel.org/stable/c/bd03a3e4c9a9df0c6b007045fa7fc8889111a478 https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824 https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711 https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815 https://lists.debian.org/debian-lts-announce/2024/06/ •