CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41061 – drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport
https://notcve.org/view.php?id=CVE-2024-41061
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. • https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85 https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41060 – drm/radeon: check bo_va->bo is non-NULL before using it
https://notcve.org/view.php?id=CVE-2024-41060
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. • https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3 https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342 https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536 •
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: -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: 8EXPL: 0CVE-2024-41046 – net: ethernet: lantiq_etop: fix double free in detach
https://notcve.org/view.php?id=CVE-2024-41046
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. • https://git.kernel.org/stable/c/504d4721ee8e432af4b5f196a08af38bc4dac5fe https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1 https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1 https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156 https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3 https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54 https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1 •