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: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38599 – jffs2: prevent xattr node from overflowing the eraseblock
https://notcve.org/view.php?id=CVE-2024-38599
In the Linux kernel, the following vulnerability has been resolved: jffs2: prevent xattr node from overflowing the eraseblock Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? • https://git.kernel.org/stable/c/aa98d7cf59b5b0764d3502662053489585faf2fe https://git.kernel.org/stable/c/2904e1d9b64f72d291095e3cbb31634f08788b11 https://git.kernel.org/stable/c/526235dffcac74c7823ed504dfac4f88d84ba5df https://git.kernel.org/stable/c/f0eea095ce8c959b86e1e57fe36ca4fea5ae54f8 https://git.kernel.org/stable/c/a1d21bcd78cf4a4353e1e835789429c6b76aca8b https://git.kernel.org/stable/c/f06969df2e40ab1dc8f4364a5de967830c74a098 https://git.kernel.org/stable/c/af82d8d2179b7277ad627c39e7e0778f1c86ccdb https://git.kernel.org/stable/c/8d431391320c5c5398ff966fb3a95e68a •
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: -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 •