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

[Kairui Song]

On Mon, Feb 2, 2026 at 1:27 PM Mikhail Gavrilov
<mikhail.v.gavrilov@xxxxxxxxx> wrote:
>
> On Mon, Feb 2, 2026 at 8:18 AM Kairui Song <ryncsn@xxxxxxxxx> wrote:
> >
> > 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.
>
> Good find! That's exactly where the problem was introduced.

Right, then I think we need a Fixes tag, and is swap really the only
victim of that change? BTW, swap's usage of page->lru will be gone
soon. Still this definitely needs to be fixed first for stable branch, but
it looks strange why nothing else ever hit this.

> Or alternatively, fix it in swapfile.c by unconditionally calling
> INIT_LIST_HEAD() - the comment there is already wrong, so we should
> fix both the comment and the code?

Or maybe clean page->private instead? The problem is triggered by
free_swap_count_continuations which checks page_private to tell if the
page has list data, and ignores the list if not. So the pages should
have their private cleaned upon allocation.

The old comment in swapfile: "Page allocation does not initialize the
page's lru field, but it does always reset its private field" does
suggest that vmalloc should take care of the private field, not sure
if that suppose to be an convention, but if swap is really the only
user of that, patching from swap side looks cleaner.