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 •
CVSS: 4.9EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41044 – ppp: reject claimed-as-LCP but actually malformed packets
https://notcve.org/view.php?id=CVE-2024-41044
In the Linux kernel, the following vulnerability has been resolved: ppp: reject claimed-as-LCP but actually malformed packets Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/97d1efd8be26615ff680cdde86937d5943138f37 https://git.kernel.org/stable/c/6e8f1c21174f9482033bbb59f13ce1a8cbe843c3 https://git.kernel.org/stable/c/3ba12c2afd933fc1bf800f6d3f6c7ec8f602ce56 https://git.kernel.org/stable/c/ebc5c630457783d17d0c438b0ad70b232a64a82f https://git.kernel.org/stable/c/3134bdf7356ed952dcecb480861d2afcc1e40492 https://git.kernel.org/stable/c/099502ca410922b56353ccef2749bc0de669da78 https://git.kernel.org/stable/c/d683e7f3fc48f59576af34631b4fb07fd • CWE-20: Improper Input Validation •
CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41042 – netfilter: nf_tables: prefer nft_chain_validate
https://notcve.org/view.php?id=CVE-2024-41042
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace). • https://git.kernel.org/stable/c/20a69341f2d00cd042e81c82289fba8a13c05a25 https://git.kernel.org/stable/c/1947e4c3346faa8ac7e343652c0fd3b3e394202f https://git.kernel.org/stable/c/cd4348e0a50286282c314ad6d2b0740e7c812c24 https://git.kernel.org/stable/c/31c35f9f89ef585f1edb53e17ac73a0ca4a9712b https://git.kernel.org/stable/c/8246b7466c8da49d0d9e85e26cbd69dd6d3e3d1e https://git.kernel.org/stable/c/b6b6e430470e1c3c5513311cb35a15a205595abe https://git.kernel.org/stable/c/717c91c6ed73e248de6a15bc53adefb81446c9d0 https://git.kernel.org/stable/c/9df785aeb7dcc8efd1d4110bb27d26005 • CWE-121: Stack-based Buffer Overflow •
CVSS: 4.7EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41041 – udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
https://notcve.org/view.php?id=CVE-2024-41041
In the Linux kernel, the following vulnerability has been resolved: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port(). syzkaller triggered the warning [0] in udp_v4_early_demux(). In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount of the looked-up sk and use sock_pfree() as skb->destructor, so we check SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace period. Currently, SOCK_RCU_FREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCK_RCU_FREE check is done too early in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race window: CPU1 CPU2 ---- ---- udp_v4_early_demux() udp_lib_get_port() | |- hlist_add_head_rcu() |- sk = __udp4_lib_demux_lookup() | |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk)); `- sock_set_flag(sk, SOCK_RCU_FREE) We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCK_RCU_FREE before inserting socket into hashtable"). Let's apply the same fix for UDP. [0]: WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738 netif_receive_skb_internal net/core/dev.c:5824 [inline] netif_receive_skb+0x271/0x300 net/core/dev.c:5884 tun_rx_batched drivers/net/tun.c:1549 [inline] tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x76f/0x8d0 fs/read_write.c:590 ksys_write+0xbf/0x190 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x41/0x50 fs/read_write.c:652 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated--- • https://git.kernel.org/stable/c/6acc9b432e6714d72d7d77ec7c27f6f8358d0c71 https://git.kernel.org/stable/c/7a67c4e47626e6daccda62888f8b096abb5d3940 https://git.kernel.org/stable/c/9f965684c57c3117cfd2f754dd3270383c529fba https://git.kernel.org/stable/c/ddf516e50bf8a7bc9b3bd8a9831f9c7a8131a32a https://git.kernel.org/stable/c/a6db0d3ea6536e7120871e5448b3032570152ec6 https://git.kernel.org/stable/c/c5fd77ca13d657c6e99bf04f0917445e6a80231e https://git.kernel.org/stable/c/20ceae10623c3b29fdf7609690849475bcdebdb0 https://git.kernel.org/stable/c/5c0b485a8c6116516f33925b9ce5b6104 • CWE-911: Improper Update of Reference Count •