In the Linux kernel, the following vulnerability has been resolved:
net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg 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 page_pool_destroy()
runs page_pool_scrub() concurrently with page return via
page_pool_put_netmem() on a different CPU. A WARN in
page_pool_clear_pp_info() surfaced the dangling DMA index bits left
by the cmpxchg loser, which led to the investigation.
page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no
page ref held. __page_pool_release_netmem_dma() currently reads and
writes netmem fields (dma_addr, DMA index bits in pp_magic) after
xa_cmpxchg() returns. The unref path calls put_page() 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:
-
__page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(),
does the cmpxchg to remove the DMA mapping, and calls dma_unmap on
the cached address. It never touches netmem fields after the cmpxchg,
making it safe for the scrub path which holds no page ref.
-
__page_pool_release_netmem_dma() wraps the above and additionally
clears dma_addr 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 (page_pool_return_netmem).
The scrub path calls __page_pool_unmap_netmem_dma() directly; the return
path calls __page_pool_release_netmem_dma().