Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
nd looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_c
ze() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when str
fore the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the
address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_T
void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/732e62212f49d549c91071b4da7942ee3058f7a2 - https://git.kernel.org/stable/c/eceb44e1f94bd641b2a4e8c09b64c797c4eabc15 - https://git.kernel.org/stable/c/6797a8b3f71b2cb558b8771a03450dc3e004e453 - https://gi
f94bd641b2a4e8c09b64c797c4eabc15 - https://git.kernel.org/stable/c/6797a8b3f71b2cb558b8771a03450dc3e004e453 - https://git.kernel.org/stable/c/4f7537772011fad832f83d6848f8eab282545bef - https://git.kernel.org/stable/c/469f9d22751472b81eaaf8a27fcdb5a70741c342 - https://git.kernel.org/stable/c/7cc183f2e67d19b03ee5c13a6664b8c6cc37ff9d
CVE ID: CVE-2025-39845 State: PUBLISHED Published: 2025-09-19T15:26:19.225Z Last Updated: 2025-11-03T17:44:00.910Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on s
chronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> It also fixes a crash in vme
e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 <TASK> vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_a
x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/744ff519c72de31344a627eaf9b24e9595aae554 - https://git.kernel.org/stable/c/5f761d40ee95d2624f839c90ebeef2d5c55007f5 - https://git.kernel.org/stable/c/26ff568f390a531d1bd792e49f1a401849921960 - https://git.kernel.org/stable/c/b7f4051dd3388edd30e9a6077c05c486aa31e0d4 - https://git.kernel.org/stable/c/6bf9473727569e8283c1e2445c7ac42cf4fc9fa9 - https://git.kernel.org/stable/c/6659d
1e0d4 - https://git.kernel.org/stable/c/6bf9473727569e8283c1e2445c7ac42cf4fc9fa9 - https://git.kernel.org/stable/c/6659d027998083fbb6d42a165b0c90dc2e8ba989
CVE ID: CVE-2025-39846 State: PUBLISHED Published: 2025-09-19T15:26:19.932Z Last Updated: 2025-11-03T17:44:02.991Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b990c8c6ff50649ad
res. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b990c8c6ff50649ad3352507398e443b1e3527b2 - https://git.kernel.org/stable/c/5ff2826c998370bf7f9ae26fe802140d220e3510 - https://git.kernel.org/stable/c/4bd570f494124608a0696da070f00236a96fb610 - https://git.kernel.org/stable/c/ce3b7766276894d2fbb07e2047a171f9deb965de - https://git.kernel.org/stable/c/2ee32c4c4f636e474cd8ab7c19a68cf36072ea93 - https://git.kernel.org/stable/c/fafa7450075f41d232bc785a4ebcbf16374f2076 - https://git.kernel.org/stable/c/d7286005e8fde0a430dc180a9f46c088c7d74483 - https://git.kernel.org/stable/c/44822df89e8f3386871d9cad563ece8e2fd8f0e7
CVE ID: CVE-2025-39847 State: PUBLISHED Published: 2025-09-19T15:26:20.648Z Last Updated: 2025-11-03T17:44:04.958Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression s
a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9ca6a040f76c0b149293e430dabab446f3fc8ab7 - https://git.kernel.org/stable/c/87a35a36742df328d0badf4fbc2e56061c15846c - https://git.kernel.org/stable/c/0b21e9cd4559102da798bdcba453b64ecd7be7ee - https://git.kernel.org/stable/c/1d8b354eafb8876d8bdb1bef69c7d2438aacfbe8 - https://git.kernel.org/stable/c/85c1c86a67e09143aa464e9bf09c397816772348 - https://git.kernel.org/sta
69c7d2438aacfbe8 - https://git.kernel.org/stable/c/85c1c86a67e09143aa464e9bf09c397816772348 - https://git.kernel.org/stable/c/631fc8ab5beb9e0ec8651fb9875b9a968e7b4ae4 - https://git.kernel.org/stable/c/33a5bac5f14772730d2caf632ae97b6c2ee95044 - https://git.kernel.org/stable/c/4844123fe0b853a4982c02666cb3fd863d701d50
CVE ID: CVE-2025-39848 State: PUBLISHED Published: 2025-09-19T15:26:21.403Z Last Updated: 2025-11-03T17:44:06.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d ("net: introduce per netns packet chains"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pid
hat ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 ("phonet: properly unshare skbs in phonet_rcv()"). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/42b46684e2c78ee052d8c2ee8d9c2089233c9094 - https://git.kernel.org/stable/c/5b079be1b9da49ad88fc304c874d4be7085f7883 - https://git.kernel.org/stable/c/2bd0f67212908243ce88e35bf69fa77155b47b14 - https://git.kernel.org/stable/c/01a2984cb803f2d487b7074f9718db2bf3531f69 - https://git.kernel.org/stable/c/7d449b7a6c8ee434d10a483feed7c
el.org/stable/c/01a2984cb803f2d487b7074f9718db2bf3531f69 - https://git.kernel.org/stable/c/7d449b7a6c8ee434d10a483feed7c5c50108cf56 - https://git.kernel.org/stable/c/89064cf534bea4bb28c83fe6bbb26657b19dd5fe - https://git.kernel.org/stable/c/b1c71d674a308d2fbc83efcf88bfc4217a86aa17 - https://git.kernel.org/stable/c/8156210d36a43e76372312c87eb5ea3dbb405a85
CVE ID: CVE-2025-39849 State: PUBLISHED Published: 2025-09-19T15:26:22.073Z Last Updated: 2025-11-03T17:44:07.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8e751d46336205abc259ed3990e850a9843fb649 - https://git.kernel.org/stable/c/e472f59d02c82b511bc43a3f96d62ed08bf4537f - https://git.kernel.org/stable/c/31229145e6ba5ace3e9391113376fa05
org/stable/c/e472f59d02c82b511bc43a3f96d62ed08bf4537f - https://git.kernel.org/stable/c/31229145e6ba5ace3e9391113376fa05b7831ede - https://git.kernel.org/stable/c/5cb7cab7adf9b1e6a99e2081b0e30e9e59d07523 - https://git.kernel.org/stable/c/62b635dcd69c4fde7ce1de4992d71420a37e51e3
CVE ID: CVE-2025-39850 State: PUBLISHED Published: 2025-09-19T15:26:22.803Z Last Updated: 2025-09-29T06:01:01.501Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC addres
not behind the "any" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK
andard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 1
addr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sen
x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0 References: - https://git.kernel.org/stable/c/e211
lf static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0 References: - https://git.kernel.org/stable/c/e211e3f4199ac829bd493632efcd131d337cba9d - https://git.kernel.org/stable/c/8cfa0f076842f9b3b4eb52ae0e41d16e25cbf8fa - https://git.kernel.org/stable/c/1f5d2fd1ca04a23c18b1bde9a43ce2fa2ffa1bce
CVE ID: CVE-2025-39851 State: PUBLISHED Published: 2025-09-19T15:26:23.576Z Last Updated: 2025-09-29T06:01:03.191Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-
therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x1
0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 lea
local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q References: - https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3 - https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307 - https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a
CVE ID: CVE-2025-39852 State: PUBLISHED Published: 2025-09-19T15:26:24.312Z Last Updated: 2025-09-29T06:01:04.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15):
cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, i
list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO. References: - https://git.kernel.org/stable/c/46d33c878fc0b3d7570366b2c9912395b3f4e701 - https://git.kernel.org/stable/c/3d2b356d994a8801acb397cafd28b13672c37ab5 - https://git.kernel.org/stable/c/fa390321aba0
https://git.kernel.org/stable/c/3d2b356d994a8801acb397cafd28b13672c37ab5 - https://git.kernel.org/stable/c/fa390321aba0a54d0f7ae95ee4ecde1358bb9234
CVE ID: CVE-2025-39853 State: PUBLISHED Published: 2025-09-19T15:26:25.101Z Last Updated: 2025-11-03T17:44:09.789Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/971feafe157afac443027acdc235badc6838560b - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/971feafe157afac443027acdc235badc6838560b - https://git.kernel.org/stable/c/3c6fb929afa313d9d11f780451d113f73922fe5d - https://git.kernel.org/stable/c/1eadabcf5623f1237a539b16586b4ed8ac8dffcd - https://git.kernel.org/stable/c/e2a5e74879f9b494bbd66fa93f355feacde450c7 - https://git.kernel.org/stable/c/fb216d980fae6561c7c70af8ef826faf059c6515 - https://git.kernel.org/stable/c/66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf - https://git.kernel.org/stable/c/9c21fc4cebd44dd21016c61261a683af390343f8 - https://git.kernel.org/stable/c/a556f06338e1d5a85af0e32ecb46e365547f92b9
CVE ID: CVE-2025-39854 State: PUBLISHED Published: 2025-09-19T15:26:25.989Z Last Updated: 2025-09-29T06:01:07.096Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps comp
of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access. References: - https://git.kernel.org/stable/c/2cde98a02da958357fe240a6ba269b69d913b6ba - https://git
ree or NULL access. References: - https://git.kernel.org/stable/c/2cde98a02da958357fe240a6ba269b69d913b6ba - https://git.kernel.org/stable/c/923c267bdbb64f65bc1149d184efcf8b047d7d64 - https://git.kernel.org/stable/c/f6486338fde3f04ed0ec59fe67a69a208c32734f