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

[Mikhail Gavrilov]

On Fri, Jan 30, 2026 at 8:31 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> Hi Mikhail,
>
> Thanks for reporting this issue.
>
> So the problem starts with `swap_map = vzalloc(maxpages);` right? Will
> it be enough if we just pass GFP_COMP here?

No, __GFP_COMP won't help here. vmalloc always calls split_page() for
high-order allocations to treat them as independent pages (see
mm/vmalloc.c around line 3730). The compound page would be split
anyway.

> 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;
> }

Yes, this comment is the root of the problem - the assumption is
incorrect for vmalloc pages obtained via split_page().
post_alloc_hook() only clears page->private for the head page
(page[0]). When split_page() breaks a high-order page into individual
pages, tail pages keep their stale page->private values.
We could fix this in swapfile.c by always calling INIT_LIST_HEAD(),
but that would only fix swap. The comment in vmalloc.c suggests other
users also rely on these fields:

"Some drivers do their own refcounting on vmalloc_to_page() pages,
some use page->mapping, page->lru, etc."

So fixing it in split_page() seems like the right place to ensure all
callers get properly initialized pages.

What do you think?

-- 
Best Regards,
Mike Gavrilov.