Answer in brief
CVE-2024-26953 records a Critical severity (CVSS 9.8) vulnerability in net: esp: fix bad handling of pages from page_pool. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <8291b4eac429c480386669444c6377573f5d8664 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <1abb20a5f4b02fb3020f88456fc1e6069b3cdc45 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <f278ff9db67264715d0d50e3e75044f8b78990f4 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <c3198822c6cb9fb588e446540485669cc81c5d34 | 8291b4eac429c480386669444c6377573f5d8664, 1abb20a5f4b02fb3020f88456fc1e6069b3cdc45, f278ff9db67264715d0d50e3e75044f8b78990f4, c3198822c6cb9fb588e446540485669cc81c5d34 |
| Linux/Linuxgeneric | 5.14 | Not reported |
| Linux/Linuxgeneric | >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <21b989b62456a0e1eae9f464a5ca360a608625d1 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <8291b4eac429c480386669444c6377573f5d8664 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <1abb20a5f4b02fb3020f88456fc1e6069b3cdc45 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <f278ff9db67264715d0d50e3e75044f8b78990f4 || >=6a5bcd84e886a9a91982e515c539529c28acdcc2 <c3198822c6cb9fb588e446540485669cc81c5d34 | 21b989b62456a0e1eae9f464a5ca360a608625d1, 8291b4eac429c480386669444c6377573f5d8664, 1abb20a5f4b02fb3020f88456fc1e6069b3cdc45, f278ff9db67264715d0d50e3e75044f8b78990f4, c3198822c6cb9fb588e446540485669cc81c5d34 |
Published upstream
May 1, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: net: esp: fix bad handling of pages from page_pool When the skb is reorganized during esp_output (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through put_page. But if the skb fragment pages are originating from a page_pool, calling put_page on them will trigger a page_pool leak which will eventually result in a crash. This leak can be easily observed when using CONFIG_DEBUG_VM and doing ipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 </TASK> The suggested fix is to introduce a new wrapper (skb_page_unref) that covers page refcounting for page_pool pages as well.
Quoted source text, attributed separately from HOL analysis.