CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38607 – macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
https://notcve.org/view.php?id=CVE-2024-38607
In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: macintosh/via-macii: Corrección "ERROR: función de suspensión llamada desde un contexto no válido" El controlador ADB via-macii llama a request_irq() después de deshabilitar las interrupciones bruscas. Pero aquí no es necesario deshabilitar las interrupciones porque la interrupción del registro de desplazamiento de VIA se enmascaró durante la inicialización de VIA1. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/e4ff8bcfb2841fe4e17e5901578b632adb89036d https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8 https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9 https://git.kernel.org/stable/c/787fb79efc15b3b86442ecf079b8148f173376d7 https://git.kernel.org/stable/c/d43a8c7ec0841e0ff91a968770aeca83f0fd4c56 https://git.kernel.org/stable/c/5900a88e897e6deb1bdce09ee34167a81 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38600 – ALSA: Fix deadlocks with kctl removals at disconnection
https://notcve.org/view.php?id=CVE-2024-38600
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. • https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7 https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68 https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7 https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4 https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c https://access.redhat.com/security/cve/CVE-2024-38600 https://bugzilla.redhat.com/show_bug.cgi?id=2293365 • CWE-833: Deadlock •
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: 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 •