CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38613 – m68k: Fix spinlock race in kernel thread creation
https://notcve.org/view.php?id=CVE-2024-38613
In the Linux kernel, the following vulnerability has been resolved: m68k: Fix spinlock race in kernel thread creation Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). • https://git.kernel.org/stable/c/533e6903bea0440816a0f517b0845ccea4cc7917 https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14 https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82 https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87 https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0 https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc •
CVSS: 9.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38612 – ipv6: sr: fix invalid unregister error path
https://notcve.org/view.php?id=CVE-2024-38612
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: sr: corrige la ruta de error de cancelación de registro no válida La ruta de error de seg6_init() es incorrecta en caso de que CONFIG_IPV6_SEG6_LWTUNNEL no esté definido. En ese caso, si seg6_hmac_init() falla, no se llama a genl_unregister_family(). Este problema existe desde que el commit 46738b1317e1 ("ipv6: sr: agregar opción para controlar la compatibilidad con lwtunnel") y el commit 5559cea2d5aa ("ipv6: sr: corregir posible use-after-free y null-ptr-deref") reemplazó unregister_pernet_subsys() con genl_unregister_family() en esta ruta de error. • https://git.kernel.org/stable/c/46738b1317e169b281ad74690276916e24d1be6d https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7 https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4 https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01 https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925 https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66 https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c • CWE-416: Use After Free CWE-476: NULL Pointer Dereference •
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.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38601 – ring-buffer: Fix a race between readers and resize checks
https://notcve.org/view.php?id=CVE-2024-38601
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix a race between readers and resize checks The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer. The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing: [ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]--- Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue. The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (! • https://git.kernel.org/stable/c/659f451ff21315ebfeeb46b9adccee8ce1b52c25 https://git.kernel.org/stable/c/b50932ea673b5a089a4bb570a8a868d95c72854e https://git.kernel.org/stable/c/c68b7a442ee61d04ca58b2b5cb5ea7cb8230f84a https://git.kernel.org/stable/c/1e160196042cac946798ac192a0bc3398f1aa66b https://git.kernel.org/stable/c/595363182f28786d641666a09e674b852c83b4bb https://git.kernel.org/stable/c/54c64967ba5f8658ae7da76005024ebd3d9d8f6e https://git.kernel.org/stable/c/af3274905b3143ea23142bbf77bd9b610c54e533 https://git.kernel.org/stable/c/5ef9e330406d3fb4f4b2c8bca2c6b8a93 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 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 •