CVSS: 7.0EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38581 – drm/amdgpu/mes: fix use-after-free issue
https://notcve.org/view.php?id=CVE-2024-38581
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix use-after-free issue Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu/mes: soluciona el problema de use-after-free. Elimina el temporizador de reserva de valla para solucionar el problema de use-after-free. v2: pasar a amdgpu_mes.c A flaw was found in the Linux kernel. This issue is due to a possible use-after-free in drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c. • https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d https://access.redhat.com/security/cve/CVE-2024-38581 https://bugzilla.redhat.com/show_bug.cgi?id=2293408 •
CVSS: 3.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38580 – epoll: be better about file lifetimes
https://notcve.org/view.php?id=CVE-2024-38580
In the Linux kernel, the following vulnerability has been resolved: epoll: be better about file lifetimes epoll can call out to vfs_poll() with a file pointer that may race with the last 'fput()'. That would make f_count go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that f_count is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless. Make sure we have a valid ref on the file pointer before we call down to vfs_poll() from the epoll routines. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: epoll: mejore la duración de los archivos epoll puede llamar a vfs_poll() con un puntero de archivo que puede competir con el último 'fput()'. Eso haría que f_count bajara a cero, y aunque el bloqueo ep->mtx significa que el desmontaje del puntero del archivo resultante se bloqueará hasta que regrese la encuesta, significa que f_count ya está muerto y no se podrá utilizar. De hecho, ya no obtengo una referencia al archivo: está muerto de todos modos. • https://git.kernel.org/stable/c/cbfd1088e24ec4c1199756a37cb8e4cd0a4b016e https://git.kernel.org/stable/c/559214eb4e5c3d05e69428af2fae2691ba1eb784 https://git.kernel.org/stable/c/4f65f4defe4e23659275ce5153541cd4f76ce2d2 https://git.kernel.org/stable/c/16e3182f6322575eb7c12e728ad3c7986a189d5d https://git.kernel.org/stable/c/4efaa5acf0a1d2b5947f98abb3acf8bfd966422b https://access.redhat.com/security/cve/CVE-2024-38580 https://bugzilla.redhat.com/show_bug.cgi?id=2293412 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38578 – ecryptfs: Fix buffer size for tag 66 packet
https://notcve.org/view.php?id=CVE-2024-38578
In the Linux kernel, the following vulnerability has been resolved: ecryptfs: Fix buffer size for tag 66 packet The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer. Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer. This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? • https://git.kernel.org/stable/c/dddfa461fc8951f9b5f951c13565b6cac678635a https://git.kernel.org/stable/c/1c125b9287e58f364d82174efb167414b92b11f1 https://git.kernel.org/stable/c/235b85981051cd68fc215fd32a81c6f116bfc4df https://git.kernel.org/stable/c/edbfc42ab080e78c6907d40a42c9d10b69e445c1 https://git.kernel.org/stable/c/12db25a54ce6bb22b0af28010fff53ef9cb3fe93 https://git.kernel.org/stable/c/0d0f8ba042af16519f1ef7dd10463a33b21b677c https://git.kernel.org/stable/c/2ed750b7ae1b5dc72896d7dd114c419afd3d1910 https://git.kernel.org/stable/c/a20f09452e2f58f761d11ad7b96b5c894 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38567 – wifi: carl9170: add a proper sanity check for endpoints
https://notcve.org/view.php?id=CVE-2024-38567
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: add a proper sanity check for endpoints Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: carl9170: agregue una verificación de integridad adecuada para los endpoints Syzkaller informa [1] que aparece una advertencia causada por la presencia de un tipo de endpoint incorrecto en la etapa de envío de URB. Si bien hubo una verificación para un cuarto endpoint específico, dado que puede cambiar de tipo entre masivo e interrupción, se confía implícitamente en otros endpoints. Se activa una advertencia similar en un par de otros problemas de syzbot [2]. Solucione el problema realizando una verificación exhaustiva de todos los endpoints teniendo en cuenta la diferencia entre la configuración de alta y máxima velocidad. [1] Informe de Syzkaller: ... • https://git.kernel.org/stable/c/a84fab3cbfdc427e7d366f1cc844f27b2084c26c https://git.kernel.org/stable/c/eb0f2fc3ff5806cc572cd9055ce7c52a01e97645 https://git.kernel.org/stable/c/ac3ed46a8741d464bc70ebdf7433c1d786cf329d https://git.kernel.org/stable/c/8650725bb0a48b206d5a8ddad3a7488f9a5985b7 https://git.kernel.org/stable/c/6a9892bf24c906b4d6b587f8759ca38bff672582 https://git.kernel.org/stable/c/265c3cda471c26e0f25d0c755da94e1eb15d7a0c https://git.kernel.org/stable/c/62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd https://git.kernel.org/stable/c/03ddc74bdfd71b84a55c9f2185d8787f2 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38553 – net: fec: remove .ndo_poll_controller to avoid deadlocks
https://notcve.org/view.php?id=CVE-2024-38553
In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: elimine .ndo_poll_controller para evitar interbloqueos. • https://git.kernel.org/stable/c/7f5c6addcdc039c1a7c435857e6284ecac5d97c8 https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243 https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5 •