Look up another CVE · open CVE-2024-26953 in the interactive tracker
CVE-2024-26953
net: esp: fix bad handling of pages from page_pool
Published 2024-05-01 (2 years ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-26953 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/linux/skbuff.h
net/ipv4/esp4.c
net/ipv6/esp6.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on include/linux/skbuff* · netdev@vger.kernel.org · Maintained
- Kernel module
- esp4
Check it on the machine
grep -wE 'CONFIG_INET|CONFIG_INET_ESP' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w esp4Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_INET, CONFIG_INET_ESP
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2024-05-01 (2 years ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.66%, higher than 50.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.14 | 6.6.24 | 8291b4eac429 |
| 5.14 | 6.7.12 | 1abb20a5f4b0 |
| 5.14 | 6.8.3 | f278ff9db672 |
| 5.14 | 6.9 | c3198822c6cb |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The vulnerable path is reached purely by received network packets — a page_pool-backed NIC RX skb forwarded into an IPsec ESP SA (`ip_list_rcv → ipgre_xmit → esp_xmit → esp_output_tail → esp_ssg_unref`), exactly as in the reported repro. No local access or syscall is involved.
- AC:LAttack complexity, low
- The attacker simply sends traffic through an IPsec gateway; packet size and fragment layout (which drive the non-inplace ESP reorganization path) are attacker-controlled and the trigger repeats on every matching packet. There is no race to win and no memory-layout precondition outside the attacker's influence.
- PR:NPrivileges required, none
- No authentication or credentials of any kind are needed — any unauthenticated remote host whose packets are routed into the ESP transform on the forwarding gateway reaches the bug. The vulnerable code runs in softirq on the transmit path with no privilege gate.
- UI:NUser interaction, none
- Triggering requires only that the attacker's packets be forwarded through the IPsec/GRE path; no action by any local user or administrator is needed beyond the pre-existing VPN configuration.
- S:UScope, unchanged
- The premature page free and the resulting corruption are both contained within the kernel's own security authority, with no crossing into a hypervisor or other authority.
- C:HConfidentiality impact, high
- The page is returned to the buddy allocator while page_pool still owns it and it remains DMA-mapped, so it can be reallocated to arbitrary kernel users while still reachable as an RX buffer — a page use-after-free permitting cross-allocation disclosure of kernel memory into network-visible buffers.
- I:HIntegrity impact, high
- The same premature free gives a write primitive: the NIC can DMA attacker-controlled packet payload into pages that have been reallocated to other kernel objects, and the residual pp_ref_count/pool tracking leads to refcount underflow and double free — memory corruption exploitable for control-flow hijacking.
- A:HAvailability impact, high
- The commit explicitly states the page_pool leak "will eventually result in a crash", with a confirmed `BUG: Bad page state` splat in softirq context; a remote attacker can drive this repeatedly to panic an IPsec gateway.