CVE-2026-90201

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:

1. __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.

2. __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().