CVE-2024-26953
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-26953
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26953.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-26953
- Downstream
- Related
- Published
- 2024-05-01T06:15:11Z
- Modified
- 2025-09-18T14:12:16Z
- Severity
-
- 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
- Summary
- [none]
- Details
-
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 espoutput (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through putpage. But if the skb fragment pages are originating from a pagepool, calling putpage on them will trigger a page_pool leak which will eventually result in a crash.
This leak can be easily observed when using CONFIGDEBUGVM 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) pagetype: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: pagepool leak Modules linked in: ipgre gre mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm ibuverbs ibcore overlay zram zsmalloc fuse [last unloaded: mlx5core] 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> dumpstacklvl+0x36/0x50 badpage+0x70/0xf0 freeunrefpageprepare+0x27a/0x460 freeunrefpage+0x38/0x120 espssgunref.isra.0+0x15f/0x200 espoutputtail+0x66d/0x780 espxmit+0x2c5/0x360 validatexmitxfrm+0x313/0x370 ? validatexmitskb+0x1d/0x330 validatexmitskblist+0x4c/0x70 schdirectxmit+0x23e/0x350 _devqueuexmit+0x337/0xba0 ? nfhookslow+0x3f/0xd0 ipfinishoutput2+0x25e/0x580 iptunnelxmit+0x19b/0x240 iptunnelxmit+0x5fb/0xb60 ipgrexmit+0x14d/0x280 [ipgre] devhardstartxmit+0xc3/0x1c0 _devqueuexmit+0x208/0xba0 ? nfhookslow+0x3f/0xd0 ipfinishoutput2+0x1ca/0x580 ipsublistrcvfinish+0x32/0x40 ipsublistrcv+0x1b2/0x1f0 ? iprcvfinishcore.constprop.0+0x460/0x460 iplistrcv+0x103/0x130 _netifreceiveskblistcore+0x181/0x1e0 netifreceiveskblistinternal+0x1b3/0x2c0 napigroreceive+0xc8/0x200 grocellpoll+0x52/0x90 _napipoll+0x25/0x1a0 netrxaction+0x28e/0x300 _dosoftirq+0xc3/0x276 ? sortrange+0x20/0x20 runksoftirqd+0x1e/0x30 smpbootthreadfn+0xa6/0x130 kthread+0xcd/0x100 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x31/0x50 ? kthreadcompleteandexit+0x20/0x20 retfromfork_asm+0x11/0x20 </TASK>
The suggested fix is to introduce a new wrapper (skbpageunref) that covers page refcounting for page_pool pages as well.
- References