CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41059 – hfsplus: fix uninit-value in copy_name
https://notcve.org/view.php?id=CVE-2024-41059
In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 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 [Fix] When allocating memory to strbuf, initialize memory to 0. • https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335 https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4 https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0 https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70 https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2 https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f7660 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41055 – mm: prevent derefencing NULL ptr in pfn_section_valid()
https://notcve.org/view.php?id=CVE-2024-41055
In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. • https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529 https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97 https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800 https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7 https://git.kernel.org/stable/c/0100aeb8a12d51950418e685f879cc80cb8e5982 https://git.kernel.org/stable/c/bc17f2377818dca643a74499c3f533350 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41049 – filelock: fix potential use-after-free in posix_lock_inode
https://notcve.org/view.php?id=CVE-2024-41049
In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen. • https://git.kernel.org/stable/c/117fb80cd1e63c419c7a221ce070becb4bfc7b6d https://git.kernel.org/stable/c/a6f4129378ca15f62cbdde09a7d3ccc35adcf49d https://git.kernel.org/stable/c/766e56faddbec2eaf70c9299e1c9ef74d846d32b https://git.kernel.org/stable/c/34bff6d850019e00001129d6de3aa4874c2cf471 https://git.kernel.org/stable/c/74f6f5912693ce454384eaeec48705646a21c74f https://git.kernel.org/stable/c/e75396988bb9b3b90e6e8690604d0f566cea403a https://git.kernel.org/stable/c/1cbbb3d9475c403ebedc327490c7c2b991398197 https://git.kernel.org/stable/c/7d4c14f4b511fd4c0dc788084ae59b465 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41048 – skmsg: Skip zero length skb in sk_msg_recvmsg
https://notcve.org/view.php?id=CVE-2024-41048
In the Linux kernel, the following vulnerability has been resolved: skmsg: Skip zero length skb in sk_msg_recvmsg When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch platform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...] This crash happens every time when running sockmap_skb_verdict_shutdown subtest in sockmap_basic. This crash is because a NULL pointer is passed to page_address() in the sk_msg_recvmsg(). Due to the different implementations depending on the architecture, page_address(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue. This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR); In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no page is put to this sge (see sg_set_page in sg_set_page), but this empty sge is queued into ingress_msg list. And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by sg_page(sge). • https://git.kernel.org/stable/c/604326b41a6fb9b4a78b6179335decee0365cd8c https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632 https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97 https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41047 – i40e: Fix XDP program unloading while removing the driver
https://notcve.org/view.php?id=CVE-2024-41047
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix XDP program unloading while removing the driver The commit 6533e558c650 ("i40e: Fix reset path while removing the driver") introduced a new PF state "__I40E_IN_REMOVE" to block modifying the XDP program while the driver is being removed. Unfortunately, such a change is useful only if the ".ndo_bpf()" callback was called out of the rmmod context because unloading the existing XDP program is also a part of driver removing procedure. In other words, from the rmmod context the driver is expected to unload the XDP program without reporting any errors. Otherwise, the kernel warning with callstack is printed out to dmesg. Example failing scenario: 1. Load the i40e driver. 2. Load the XDP program. 3. Unload the i40e driver (using "rmmod" command). The example kernel warning log: [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.002726] Call Trace: [ +0.002457] <TASK> [ +0.002119] ? • https://git.kernel.org/stable/c/b82364abc54b19829b26459989d2781fc4822c28 https://git.kernel.org/stable/c/6533e558c6505e94c3e0ed4281ed5e31ec985f4d https://git.kernel.org/stable/c/2754d83160c96ae22afff8687ddb575d3b790587 https://git.kernel.org/stable/c/b399a68054dfb36eed121846ef5fcddba40b7740 https://git.kernel.org/stable/c/4bc336b2345f1485438c0eb7246d9c8a8d09f8ff https://git.kernel.org/stable/c/5266302cb2c74d8ab0e9a69d5752fffaea70496e https://git.kernel.org/stable/c/0075b8c94d76830c7b6f018f6e4eeb0bf6465fdc https://git.kernel.org/stable/c/01fc5142ae6b06b61ed51a624f2732d65 •