CVSS: 6.7EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36899 – gpiolib: cdev: Fix use after free in lineinfo_changed_notify
https://notcve.org/view.php?id=CVE-2024-36899
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige el use after free en lineinfo_changed_notify El problema de use after free ocurre de la siguiente manera: cuando el archivo del dispositivo del chip GPIO se cierra al invocar gpio_chrdev_release(), las líneas vigiladas son liberado por bitmap_free(), pero la cancelación del registro de la cadena de notificador lineinfo_changed_nb falló debido a la espera de escritura de rwsem. • https://git.kernel.org/stable/c/51c1064e82e77b39a49889287ca50709303e2f26 https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239 https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da https://access.redhat.com/security/cve/CVE-2024-36899 https://bugzilla.redhat.com/show_bug.cgi?id=2284549 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36898 – gpiolib: cdev: fix uninitialised kfifo
https://notcve.org/view.php?id=CVE-2024-36898
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige kfifo no inicializado Si se solicita una línea con antirrebote, y eso resulta en un antirrebote en el software, y la línea se reconfigura posteriormente para habilitar la detección de bordes, entonces se realiza la asignación del Se pasa por alto kfifo para contener eventos de borde. Esto da como resultado que los eventos se escriban y lean desde un kfifo no inicializado. • https://git.kernel.org/stable/c/65cff70464068a823b3f4a28074000febdce0630 https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5 https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2 https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36897 – drm/amd/display: Atom Integrated System Info v2_2 for DCN35
https://notcve.org/view.php?id=CVE-2024-36897
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Atom Integrated System Info v2_2 for DCN35 New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Atom Integrated System Info v2_2 para DCN35 Nueva solicitud de KMD/VBIOS para admitir el nuevo modelo de exclusión UMA. Esto corrige una desreferencia nula al acceder a Ctx->dc_bios->integrated_info mientras era NULL. DAL analiza el BIOS y extrae la información integrada necesaria, pero faltaba un caso para la nueva versión 2.3 del BIOS. • https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0 https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60 • CWE-476: NULL Pointer Dereference •
CVSS: 9.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36896 – USB: core: Fix access violation during port device removal
https://notcve.org/view.php?id=CVE-2024-36896
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix access violation during port device removal Testing with KASAN and syzkaller revealed a bug in port.c:disable_store(): usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value. It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems. The same bug exists in the disable_show() routine, and it can be fixed the same way. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: core: corrige la infracción de acceso durante la eliminación del dispositivo del puerto. Las pruebas con KASAN y syzkaller revelaron un error en port.c:disable_store(): usb_hub_to_struct_hub() puede devolver NULL si el hub que el puerto al que pertenece se elimina simultáneamente, pero la función no comprueba esta posibilidad antes de desreferenciar el valor devuelto. Resulta que la primera desreferencia es innecesaria, ya que hub->intfdev es el padre del dispositivo portuario, por lo que se puede cambiar fácilmente. • https://git.kernel.org/stable/c/f061f43d7418cb62b8d073e221ec75d3f5b89e17 https://git.kernel.org/stable/c/5f1d68ef5ddac27c6b997adccd1c339cef1e6848 https://git.kernel.org/stable/c/63533549ff53d24daf47c443dbd43c308afc3434 https://git.kernel.org/stable/c/6119ef6517ce501fc548154691abdaf1f954a277 https://git.kernel.org/stable/c/a4b46d450c49f32e9d4247b421e58083fde304ce https://access.redhat.com/security/cve/CVE-2024-36896 https://bugzilla.redhat.com/show_bug.cgi?id=2284556 • CWE-170: Improper Null Termination CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36895 – usb: gadget: uvc: use correct buffer size when parsing configfs lists
https://notcve.org/view.php?id=CVE-2024-36895
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: use correct buffer size when parsing configfs lists This commit fixes uvc gadget support on 32-bit platforms. Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for reuse") introduced a helper function __uvcg_iter_item_entries() to aid with parsing lists of items on configfs attributes stores. This function is a generalization of another very similar function, which used a stack-allocated temporary buffer of fixed size for each item in the list and used the sizeof() operator to check for potential buffer overruns. The new function was changed to allocate the now variably sized temp buffer on heap, but wasn't properly updated to also check for max buffer size using the computed size instead of sizeof() operator. As a result, the maximum item size was 7 (plus null terminator) on 64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just barely enough, 3 is definitely too small for some of UVC configfs attributes. For example, dwFrameInteval, specified in 100ns units, usually has 6-digit item values, e.g. 166666 for 60fps. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: gadget: uvc: use el tamaño de búfer correcto al analizar listas de configfs. • https://git.kernel.org/stable/c/0df28607c5cb4fe60bba591e9858a8f7ba39aa4a https://git.kernel.org/stable/c/7a54e5052bde582fd0e7677334fe7a5be92e242c https://git.kernel.org/stable/c/a422089ce42ced73713e5032aad29a9a7cbe9528 https://git.kernel.org/stable/c/650ae71c80749fc7cb8858c8049f532eaec64410 •