linux-kernel - Re: [RFC PATCH] mm/page_alloc: fix use-after-free in swap due to stale page data after split

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMgjq7BM0QFvk3_D4qyggjJ4W_+nHAupQnpAYehGq50CYNJV7w@mail.gmail.com>
Date: Fri, 30 Jan 2026 23:30:33 +0800
From: Kairui Song <ryncsn@...il.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc: Linux Memory Management List <linux-mm@...ck.org>, 
	Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Vlastimil Babka <vbabka@...e.cz>, chrisl@...nel.org, Hugh Dickins <hughd@...gle.com>
Subject: Re: [RFC PATCH] mm/page_alloc: fix use-after-free in swap due to
 stale page data after split_page()

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