Re: [RFC PATCH] mm/page_alloc: fix use-after-free in swap due to stale page data after split_page()

[Kairui Song <ryncsn@gmail.com>]

On Fri, Jan 30, 2026 at 9:49 PM Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> 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;
}