Linux kernel mm: stale page->private survives page free and causes a use-after-free in the swap subsystem

Impact

Several subsystems - slub, shmem and the DRM TTM memory manager among them - set page->private and do not clear it before freeing the page. When such a page is later handed out as a high-order allocation and split with split_page(), the tail pages carry the stale value. The swap code assumes a freshly allocated page has page->private == 0 when it tracks swap count continuations, so it follows what it believes is a valid continuation list and walks uninitialized page->lru entries holding LIST_POISON, producing a use-after-free that KASAN reports as a wild memory access in the swapoff path. Realistically this is a node stability and memory-corruption problem rather than a clean escalation primitive, and it only bites where swap is actually in use - many GPU nodes run with swap off, which takes them out of the reported crash path. TTM appearing on the list of subsystems that leave page->private set means GPU-heavy nodes are among those that generate the stale pages in the first place.

Who can reach it

Local, unprivileged-to-low-privileged workload on the host: any code path that allocates and frees pages through the affected subsystems, followed by the swap subsystem consuming a split high-order page. Triggering it deliberately requires local execution on the node and a swap-enabled configuration; the crash was reported via swapoff.

What to do

Update to a stable kernel that clears page->private in free_pages_prepare() and reboot each affected node - a drain and reboot per GPU host, with no live-patch path since the fix is in the page allocator's free path. Where nodes already run without swap, the reported crash path is not reachable and the update can ride the next scheduled kernel roll rather than an emergency window; confirm with swapon --show per node rather than assuming.

References

Related entries

• Linux kernel (net/rds): When pinning user pages for a zerocopy RDS send fails, the pages are released but theCVE-2026-43494 · Linux kernel (net/rds)High
• Linux kernel (net/rds): A zerocopy RDS send that fails after pinning user pages but before the message reaches theCVE-2026-43502 · Linux kernel (net/rds)High
• Linux kernel BPF: negative CO-RE accessor index causes an out-of-bounds read and deterministic kernel crashCVE-2026-45839 · Linux kernel BPF verifier (bpf_core_parse_spec CO-RE accessor parsing)High
• Linux kernel (drivers/iommu/intel): VT-d publishes the address of a freshly allocated PASID table into the PASIDCVE-2026-45862 · Linux kernel (drivers/iommu/intel)High
• Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd): An out-of-bounds access in the amdkfd (KFD computeCVE-2026-45878 · Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd)High
• Linux kernel (drivers/iommu/intel): The 512-bit VT-d PASID entry is zeroed all at once while still marked present, andCVE-2026-45894 · Linux kernel (drivers/iommu/intel)High