Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
50 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fo
workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512
64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc
he buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/03dcdd2558e1e55bf843822fe4363dcb48743f2b - https://git.kernel.org/stable/c/15a6f4971e2f157d57e09ea748d1fbc714277aa4 - https://git.kernel.org/stable/c/dab8ded2e5ff41012a6ff400b44dbe76ccf3592a - https://git.kernel.org/stable/c/1dbf7cd2454a28b1da700085b99
rnel.org/stable/c/dab8ded2e5ff41012a6ff400b44dbe76ccf3592a - https://git.kernel.org/stable/c/1dbf7cd2454a28b1da700085b99346b5445aeabb - https://git.kernel.org/stable/c/be4b8392da7978294f2f368799d29dd509fb6c4d - https://git.kernel.org/stable/c/50aa2d121bc2cfe2d825f8a331ea75dfaaab6a50 - https://git.kernel.org/stable/c/3b89e17b2fd64012682bed158d9eb3d2e96dec42 - https://git.kernel.org/stable/c/667eeab4999e981c96b447a4df5f20bdf5c26f13
CVE ID: CVE-2025-38465 State: PUBLISHED Published: 2025-07-25T15:27:47.510Z Last Updated: 2025-11-03T17:38:27.585Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netlink: Fix wraparounds of sk->sk_rmem_alloc. Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc); , which has the same problem fixed by commit 5a465a0da13e ("udp: Fix multiple wraparounds of sk->sk_rmem_alloc."). For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until
he condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc. Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int. Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 * After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9da025150b7c14a8390fc06aea314c0a4011e82c -
otes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9da025150b7c14a8390fc06aea314c0a4011e82c - https://git.kernel.org/stable/c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98 - https://git.kernel.org/stable/c/fd69af06101090eaa60b3d216ae715f9c0a58e5b - https://git.kernel.org/stable/c/76602d8e13864524382b0687dc32cd8f19164d5a - https://git.kernel.org/stable/c/55baecb9eb90238f60a8350660d6762046ebd3bd - https://git.kernel.org/stable/c/4b8e18af7bea92f8b7fb92d40aeae729209db250 - https://git.kernel.org/stable/c/cd7ff61bfffd7000143c42bbffb85eeb792466d6 - https://git.kernel.org/stable/c/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc
CVE ID: CVE-2025-38466 State: PUBLISHED Published: 2025-07-25T15:27:48.235Z Last Updated: 2025-11-03T17:38:29.560Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf: Revert to requiring CAP_SYS_ADMIN for uprobes Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can
itionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d7ef1afd5b3f43f4924326164cee5397b66abd9c - https://git.kernel.org/stable/c/c0aec35f861fa746ca45aa816161c74352e6ada8 - https://git.kernel.org/stable/c/8e8bf7bc6aa6f583336c2fda280b6cea0aed5612 - https://git.kernel.org/stable/c/183bdb89af1b5193b1d1d9316986053b15ca6fa4 - https://git.kernel.org/stable/c/a0a8009083e569b5526c64f7d3f2a62baca95164 - https://git.kernel.org/stable/c/d507
ca6fa4 - https://git.kernel.org/stable/c/a0a8009083e569b5526c64f7d3f2a62baca95164 - https://git.kernel.org/stable/c/d5074256b642cdeb46a70ce2f15193e766edca68 - https://git.kernel.org/stable/c/ba677dbe77af5ffe6204e0f3f547f3ba059c6302
CVE ID: CVE-2025-38467 State: PUBLISHED Published: 2025-07-25T15:27:49.045Z Last Updated: 2025-11-03T17:38:31.497Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates tha
rtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b4e72c0bf878f02faa00a7dc7c9ffc4ff7c116a7 - https://git.kernel.org/stable/c/a2130463fc9451005660b0eda7b61d5f746f7d74 - https://git.kernel.org/stable/c/87825fbd1e176cd5b896940f3959e7c9a916945d - https://git.kernel.org/stable/c/a40a35166f7e4f6dcd4b087d620c8228922dcb0a - https://git.kernel.org/stable/c/391e5ea5b877230b844c9bd8bbcd91b
.org/stable/c/a40a35166f7e4f6dcd4b087d620c8228922dcb0a - https://git.kernel.org/stable/c/391e5ea5b877230b844c9bd8bbcd91b681b1ce2d - https://git.kernel.org/stable/c/e9d9b25f376737b81f06de9c5aa422b488f47184 - https://git.kernel.org/stable/c/996740652e620ef8ee1e5c65832cf2ffa498577d - https://git.kernel.org/stable/c/b846350aa272de99bf6fecfa6b08e64ebfb13173
CVE ID: CVE-2025-38468 State: PUBLISHED Published: 2025-07-28T11:12:20.188Z Last Updated: 2025-11-03T17:38:33.418Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree whi
3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns N
btree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify()
lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@wil
/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fed3570e548a6c9f95c5f4c9e1a7afc1679fd90d - https://git.kernel.org/stable/c/5c0506cd1b1a3b145bda2612bbf7fe78d186c355 - https://git.kernel.org/stable/c/850226aef8d28a00cf966ef26d2f8f2bff344535 - https://git.kernel.org/stable/c/890a5d423ef0a7bd13447ceaffad21189f557301 - https://git.kernel.org/stable/c/7ff2d83ecf2619060f30ecf9fad4f2a700fca344 - https://git.kernel.org/stable/c/e5c480dc62a3025b8428d4818e722da30ad6804f - https://git.kernel.org/stable/c/3691f84269a23f7edd263e
it.kernel.org/stable/c/e5c480dc62a3025b8428d4818e722da30ad6804f - https://git.kernel.org/stable/c/3691f84269a23f7edd263e9b6edbc27b7ae332f4 - https://git.kernel.org/stable/c/0e1d5d9b5c5966e2e42e298670808590db5ed628
CVE ID: CVE-2025-38469 State: PUBLISHED Published: 2025-07-28T11:21:30.992Z Last Updated: 2025-07-28T11:21:30.992Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host for more than one event channel potr (nr_ports > 1). After the kmalloc_array(), the error paths need to go through the "out" label, but the call to kvm_read_guest_virt() does not. [Adjusted commit message. - Paolo] References: - https://git.kernel.org/stable/c/3ee59c38ae7369ad1f7b846e05633ccf0d159fab - https://git.kernel.org/s
Paolo] References: - https://git.kernel.org/stable/c/3ee59c38ae7369ad1f7b846e05633ccf0d159fab - https://git.kernel.org/stable/c/fd627ac8a5cff4d45269f164b13ddddc0726f2cc - https://git.kernel.org/stable/c/061c553c66bc1638c280739999224c8000fd4602 - https://git.kernel.org/stable/c/5a53249d149f48b558368c5338b9921b76a12f8c
CVE ID: CVE-2025-38470 State: PUBLISHED Published: 2025-07-28T11:21:32.002Z Last Updated: 2025-11-03T17:38:35.299Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up t
y leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for re
the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan
lan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex du
an-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1
_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8
000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ba48d3993af23753e1f1f01c8d592de9c7785f24 - https://git
Program Container: References: - https://git.kernel.org/stable/c/ba48d3993af23753e1f1f01c8d592de9c7785f24 - https://git.kernel.org/stable/c/35142b3816832889e50164d993018ea5810955ae - https://git.kernel.org/stable/c/047b61a24d7c866c502aeeea482892969a68f216 - https://git.kernel.org/stable/c/d43ef15bf4856c8c4c6c3572922331a5f06deb77 - https://git.kernel.org/stable/c/bb515c41306454937464da055609b5fb0a27821b - https://git.kernel.org/stable/c/8984bcbd1edf5bee5be06ad771d157333b790c33 - https://git.kernel.org/stable/c/93715aa2d80e6c5cea1bb486321fc4585076928b - https://git.kernel.org/stable/c/579d4f9ca9a9a605184a9b162355f6ba131f678d
CVE ID: CVE-2025-38471 State: PUBLISHED Published: 2025-07-28T11:21:32.927Z Last Updated: 2025-11-03T17:38:36.234Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: always refresh the queue when reading sock After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/1352
s/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len"). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/730fed2ff5e259495712518e18d9f521f61972bb - https://git.kernel.org/stable/c/1f3a429c21e0e43e8b8c55d30701e914
org/stable/c/730fed2ff5e259495712518e18d9f521f61972bb - https://git.kernel.org/stable/c/1f3a429c21e0e43e8b8c55d30701e91411a4df02 - https://git.kernel.org/stable/c/cdb767915fc9a15d88d19d52a1455f1dc3e5ddc8 - https://git.kernel.org/stable/c/c76f6f437c46b2390888e0e1dc7aafafa9f4e0c6 - https://git.kernel.org/stable/c/4ab26bce3969f8fd925fe6f6f551e4d1a508c68b
CVE ID: CVE-2025-38472 State: PUBLISHED Published: 2025-07-28T11:21:33.977Z Last Updated: 2025-11-03T17:38:37.206Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn st
d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected
: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x cpu y cpu z found entry E found entry E E is expired <preemption> nf_ct_delete() return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. ->refcnt set to
n cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable. cpu y resumes, it observes E as expired but CONFIRMED: <resumes> nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set. cpu y will try to delete E from the hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock
YING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP <unblocks, then crashes on hlist_nulls_del_rcu pprev> In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_connt