Re: [RFC PATCH] mm/page_alloc: fix use-after-free in swap due to stale page data after split_page()
From: Kairui Song
Date: Fri Jan 30 2026 - 10:31:19 EST
On Fri, Jan 30, 2026 at 9:49 PM Mikhail Gavrilov
<mikhail.v.gavrilov@xxxxxxxxx> wrote:
>
> Hi,
>
> I've been debugging a use-after-free bug in the swap subsystem that manifests
> as a crash in free_swap_count_continuations() during swapoff on zram devices.
>
> == Problem ==
>
> KASAN reports wild-memory-access at address 0xdead000000000100 (LIST_POISON1):
>
> Oops: general protection fault, probably for non-canonical address
> 0xfbd59c0000000020
> KASAN: maybe wild-memory-access in range
> [0xdead000000000100-0xdead000000000107]
> RIP: 0010:__do_sys_swapoff+0x1151/0x1860
>
> RBP: dead0000000000f8
> R13: dead000000000100
>
> The crash occurs when free_swap_count_continuations() iterates over a
> list_head containing LIST_POISON values from a previous list_del().
>
Hi Mikhail,
Thanks for reporting this issue.
> == Root Cause ==
>
> The swap subsystem uses vmalloc_to_page() to get struct page pointers for
> the swap_map array, then uses page->private and page->lru for swap count
> continuation lists.
>
> When vmalloc allocates high-order pages without __GFP_COMP and splits them
> via split_page(), the resulting pages may contain stale data:
So the problem starts with `swap_map = vzalloc(maxpages);` right? Will
it be enough if we just pass GFP_COMP here?
And worth noting, mm/swapfile.c already have following code:
/*
* Page allocation does not initialize the page's lru field,
* but it does always reset its private field.
*/
if (!page_private(head)) {
BUG_ON(count & COUNT_CONTINUED);
INIT_LIST_HEAD(&head->lru);
set_page_private(head, SWP_CONTINUED);
si->flags |= SWP_CONTINUED;
}