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: 5.5EPSS: 0%CPEs: 11EXPL: 0CVE-2024-38598 – md: fix resync softlockup when bitmap size is less than array size
https://notcve.org/view.php?id=CVE-2024-38598
In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: <TASK> md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: corrige el bloqueo suave de resincronización cuando el tamaño del mapa de bits es menor que el tamaño de la matriz. Se informa que para dm-raid10, lvextend + lvchange --syncaction activará el siguiente bloqueo suave: kernel:watchdog: ERROR : bloqueo suave - ¡CPU n.° 3 bloqueada durante 26 segundos! • https://git.kernel.org/stable/c/374fb914304d9b500721007f3837ea8f1f9a2418 https://git.kernel.org/stable/c/b0b971fe7d61411ede63c3291764dbde1577ef2c https://git.kernel.org/stable/c/39fa14e824acfd470db4f42c354297456bd82b53 https://git.kernel.org/stable/c/a134dd582c0d5b6068efa308bd485cf1d00b3f65 https://git.kernel.org/stable/c/be1a3ec63a840cc9e59a033acf154f56255699a1 https://git.kernel.org/stable/c/301867b1c16805aebbc306aafa6ecdc68b73c7e5 https://git.kernel.org/stable/c/152bb26796ff054af50b2ee1b3ca56e364e4f61b https://git.kernel.org/stable/c/bea301c046110bf421a3ce153fb868cb8 • CWE-667: Improper Locking •
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') •