CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35822 – usb: udc: remove warning when queue disabled ep
https://notcve.org/view.php?id=CVE-2024-35822
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug(). • https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8 https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290 https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f0257 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35817 – drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
https://notcve.org/view.php?id=CVE-2024-35817
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: amdgpu_ttm_gart_bind establece el indicador vinculado a gtt. De lo contrario, después de que se libera GTT bo, se libera el espacio GTT y gart, pero amdgpu_ttm_backend_unbind no borrará la entrada de la tabla de páginas de gart y dejará una asignación válida. entrada que apunta a la página del sistema obsoleto. Luego, si la GPU accede a la dirección de Gart por error, leerá un valor indefinido en lugar de un error de página, lo que será más difícil de depurar y reproducir el problema real. • https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3 https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6 https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3 https://access.redhat.com/security/cve/CVE-2024-35817 https://bugzilla.redhat.com/show_bug.cgi?id=2281202 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35809 – PCI/PM: Drain runtime-idle callbacks before driver removal
https://notcve.org/view.php?id=CVE-2024-35809
In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. • https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6 https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1 https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491 https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674 https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989 https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5 https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35805 – dm snapshot: fix lockup in dm_exception_table_exit
https://notcve.org/view.php?id=CVE-2024-35805
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm snapshot: corregido el bloqueo en dm_exception_table_exit Se informó un bloqueo cuando salimos de un snapshot con muchas excepciones. Solucione este problema agregando "cond_resched" al bucle que libera las excepciones. • https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7 https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1 https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2 https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366 https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683 https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef285 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35803 – x86/efistub: Call mixed mode boot services on the firmware's stack
https://notcve.org/view.php?id=CVE-2024-35803
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. • https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926 https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31 https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 •