CVE-2026-90201: net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg race
In the Linux kernel, the following vulnerability has been resolved:
net: pagepool: fix UAF in pagepoolreleasenetmemdma on xacmpxchg race
This bug was discovered while testing the hns3 driver under channel reconfiguration (ethtool -L / ethtool -G) with iperf3 traffic on arm64. The race is intermittently triggered when pagepooldestroy() runs pagepoolscrub() concurrently with page return via pagepoolputnetmem() on a different CPU. A WARN in pagepoolclearppinfo() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation.
pagepoolscrub() iterates pool->dmamapped via xaforeach() with no page ref held. pagepoolreleasenetmemdma() currently reads and writes netmem fields (dmaaddr, DMA index bits in ppmagic) after xacmpxchg() returns. The unref path calls putpage() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free.
Fix this by splitting the DMA release into two functions:
1. pagepoolunmapnetmemdma() caches dmaaddr before xacmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dmaunmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref.
2. pagepoolreleasenetmemdma() wraps the above and additionally clears dmaaddr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (pagepoolreturnnetmem).
The scrub path calls pagepoolunmapnetmemdma() directly; the return path calls pagepoolreleasenetmemdma().
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger this issue?
The race requires page_pool_destroy() to run page_pool_scrub() concurrently with page return through page_pool_put_netmem() on another CPU. It was intermittently observed during hns3 channel reconfiguration using ethtool -L or ethtool -G while iperf3 traffic was active on arm64.
Which systems are most likely exposed?
Systems using the Linux kernel page_pool code and exercising concurrent page-pool teardown and page return are relevant. The reported test case involved the hns3 driver, active network traffic, and channel reconfiguration; the provided data does not establish that this is limited to hns3 or arm64.
How can an affected system present?
Testing exposed a WARN in page_pool_clear_pp_info() caused by dangling DMA index bits after the xa_cmpxchg loser path. The underlying condition is a use-after-free in which page_pool_scrub() can access a page after another path frees it.