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 11:47 PM Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> On Fri, Jan 30, 2026 at 8:31 PM Kairui Song <ryncsn@gmail.com> 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.

Right, but with __GFP_COMP, prep_compound_page clears the tail pages'
private too, so the code snip I posted will clear their lru on use?

>
> > 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?

I took a look at the history, commit 3b8000ae185c ("mm/vmalloc: huge
vmalloc backing pages should be split rather than compound") dropped
__GFP_COMP and added split_page, that's the commit added the comment
you mentioned.

Fixing it with this patch you posted seems could result in other
issues, e.g. split_free_pages / split_free_frozen_pages would call
split_page while the page is on a list, so at least clearing head
page's LRU seems incorrect?