CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41050 – cachefiles: cyclic allocation of msg_id to avoid reuse
https://notcve.org/view.php?id=CVE-2024-41050
In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msg_id to avoid reuse Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6 process_open_req copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msg_id reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time. • https://git.kernel.org/stable/c/c8383054506c77b814489c09877b5db83fd4abf2 https://git.kernel.org/stable/c/35710c6c4a1c64478ec1b5e0e81d386c0844dec6 https://git.kernel.org/stable/c/de045a82e1a4e04be62718d3c2981a55150765a0 https://git.kernel.org/stable/c/9d3bf4e9aa23f0d9e99ebe7a94f232ddba54ee17 https://git.kernel.org/stable/c/19f4f399091478c95947f6bd7ad61622300c30d9 •
CVSS: 7.0EPSS: 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 • CWE-416: Use After Free •
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 •
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 •