CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-38597 – eth: sungem: remove .ndo_poll_controller to avoid deadlocks
https://notcve.org/view.php?id=CVE-2024-38597
In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: sungem: elimine .ndo_poll_controller para evitar interbloqueos Erhard informa advertencias de netpoll desde sungem: netpoll_send_skb_on_dev(): eth0 habilitó interrupciones en la encuesta (gem_start_xmit+0x0/0x398) ADVERTENCIA: CPU: 1 PID: 1 en net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() desactiva las interrupciones, que pueden dormir. No podemos dormir en netpoll, tiene las interrupciones desactivadas por completo. Curiosamente, gem_poll_controller() ni siquiera sondea las finalizaciones y, en cambio, actúa como si se hubiera disparado una interrupción, por lo que simplemente programa NAPI y sale. • https://git.kernel.org/stable/c/fe09bb619096a0aa139210748ddc668c2dbe2308 https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289 https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6 https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937 https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd69 •
CVSS: 4.7EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38596 – af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
https://notcve.org/view.php?id=CVE-2024-38596
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/fca6072e1a7b1e709ada5604b951513b89b4bd0a https://git.kernel.org/stable/c/de6641d213373fbde9bbdd7c4b552254bc9f82fe https://git.kernel.org/stable/c/4d51845d734a4c5d079e56e0916f936a55e15055 https://git.kernel.org/stable/c/9aa8773abfa0e954136875b4cbf2df4cf638e8a5 https://git.kernel.org/stable/c/8299e4d778f664b31b67cf4cf3d5409de2ecb92c https://git.kernel.org/stable/c/0688d4e499bee3f2749bca27329bd128686230cb https://git.kernel.org/stable/c/a4c88072abcaca593cefe70f90e9d3707 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38589 – netrom: fix possible dead-lock in nr_rt_ioctl()
https://notcve.org/view.php?id=CVE-2024-38589
In the Linux kernel, the following vulnerability has been resolved: netrom: fix possible dead-lock in nr_rt_ioctl() syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netrom: solucionó un posible bloqueo en nr_rt_ioctl() syzbot ama netrom y encontró un posible bloqueo en nr_rt_ioctl [1] Asegúrese de adquirir siempre nr_node_list_lock antes de nr_node_lock(nr_node) [1 ] ADVERTENCIA: se detectó posible dependencia de bloqueo circular 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 No contaminado --------------------- --------------------- syz-executor350/5129 está intentando adquirir el bloqueo: ffff8880186e2070 (&nr_node->node_lock){+... }-{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, en: nr_node_lock include/net/ netrom.h:152 [en línea] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:464 [en línea] ffff8880186e2070 (&nr_node->node_lock) {+...}-{2:2}, en: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 pero la tarea ya está bloqueada: fffffffff8f7053b8 (nr_node_list_lock){+...}-{2: 2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] fffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:462 [en línea] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/ spinlock_api_smp.h:126 [en línea] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [en línea] nr_remove_node net/netrom/nr_route.c:299 [en línea] nr_del_node+ 0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:13 41 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64 +0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep. c:3134 [en línea] check_prevs_add kernel/locking/lockdep.c:3253 [en línea] validar_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed /0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [en línea] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [en línea ] nr_node_lock include/net/netrom.h:152 [en línea] nr_dec_obs net/netrom/nr_route.c:464 [en línea] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket. c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 llamada_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- bloqueo(nr_node_list_lock); bloquear(&nr_nodo->nodo_lock); bloquear(nr_node_list_lock); bloquear(&nr_nodo->nodo_lock); *** DEADLOCK *** 1 bloqueo retenido por syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [ en línea] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, en: nr_dec_obs net/netrom/nr_route.c:462 [en línea] #0: ffffffff8f70 ---truncado--- • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691 https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5 https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7 https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8 https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0 •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38588 – ftrace: Fix possible use-after-free issue in ftrace_location()
https://notcve.org/view.php?id=CVE-2024-38588
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix possible use-after-free issue in ftrace_location() KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. • https://git.kernel.org/stable/c/ae6aa16fdc163afe6b04b6c073ad4ddd4663c03b https://git.kernel.org/stable/c/eea46baf145150910ba134f75a67106ba2222c1b https://git.kernel.org/stable/c/1880a324af1c95940a7c954b6b937e86844a33bd https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831 https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461 https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6 https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38583 – nilfs2: fix use-after-free of timer for log writer thread
https://notcve.org/view.php?id=CVE-2024-38583
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of timer for log writer thread Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el use-after-free del temporizador para el hilo del escritor de registros Serie de parches "nilfs2: corrige problemas relacionados con el escritor de registros". Esta serie de corrección de errores cubre tres problemas relacionados con el escritor de registros nilfs2, incluido un problema de use-after-free del temporizador y un posible problema de bloqueo al desmontar, y un posible problema de congelación en la sincronización de eventos encontrado durante su análisis. Los detalles se describen en cada registro de confirmación. • https://git.kernel.org/stable/c/fdce895ea5dd4e24edf1f4d693827349a4e5b3b4 https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164 https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148 https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438 https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0 https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d •