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: 5.3EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38582 – nilfs2: fix potential hang in nilfs_detach_log_writer()
https://notcve.org/view.php?id=CVE-2024-38582
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: soluciona un posible bloqueo en nilfs_detach_log_writer() Syzbot ha informado de un posible bloqueo en nilfs_detach_log_writer() llamado durante el desmontaje de nilfs2. El análisis reveló que esto se debe a que nilfs_segctor_sync(), que se sincroniza con el hilo del escritor de registros, puede ser llamado después de que nilfs_segctor_destroy() finalice ese hilo, como se muestra en el seguimiento de llamadas a continuación: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Apagar el hilo del escritor de registros Flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (si el inodo necesita sincronización) nilfs_segctor_sync --> Intente sincronizar con el hilo del escritor de registros *** DEADLOCK *** Solucione este problema cambiando nilfs_segctor_sync() para que el hilo del escritor de registros regrese normalmente sin sincronizarse después de que termine y forzando las tareas que ya están esperando a completarse una vez que finaliza el hilo. La eliminación de metadatos del inodo omitido se procesará en conjunto en el trabajo de limpieza posterior en nilfs_segctor_destroy(). • https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830 https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0 https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728 •
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: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38538 – net: bridge: xmit: make sure we have at least eth header len bytes
https://notcve.org/view.php?id=CVE-2024-38538
In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: xmit: asegúrese de tener al menos el encabezado eth len bytes syzbot desencadenó un error de valor uninit[1] en la ruta xmit del dispositivo puente al enviar un mensaje corto (menos de ETH_HLEN bytes) skb. Para solucionarlo, compruebe si realmente podemos retirar esa cantidad en lugar de suponerla. Probado con dropwatch: soltar en: br_dev_xmit+0xb93/0x12d0 [puente] (0xffffffffc06739b3) origen: marca de tiempo del software: lunes 13 de mayo 11:31:53 2024 778214037 protocolo nsec: 0x88a8 longitud: 2 longitud original: 2 motivo de caída: PKT_TOO_SMALL [1 ] ERROR: KMSAN: valor uninit en br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev .c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] __bpf_tx_skb net/core/filter.c:2136 [en línea] __bpf_redirect_common net/core/filter.c:2180 [en línea] __bpf_redirect+0x14a6/0x1620 net/ Core/Filter.C: 2187 ____BPF_CLONE_REDIRECT NET/CORE/FILTRO.C: 2460 [Inline] BPF_CLONE_REDIRECT+0x328/0x470 NET/Core/Filter.c: 2432 ___ BPF_PROG_RUN+0X13FE/0XE0F0 KERNEL/BPF/BPF/CORE. 0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [en línea] __bpf_prog_run include/linux/filter.h:657 [en línea] bpf_prog_run include/linux/filter.h:664 [en línea ] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 pf+0x6aa/0xd90 núcleo/ bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5765 [en línea] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 ys_call+0x96b /0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+ 0x77/0x7f • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2 https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5 https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2 https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc https://access.redhat.com/security/cve/CVE-2024-38538 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •