linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: Kairui Song <ryncsn@gmail.com>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	 Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	chrisl@kernel.org, Hugh Dickins <hughd@google.com>
Subject: Re: [RFC PATCH] mm/page_alloc: fix use-after-free in swap due to stale page data after split_page()
Date: Tue, 3 Feb 2026 01:21:30 +0500	[thread overview]
Message-ID: <CABXGCsPPeKCqj4KB3Cp0r=rWd+0KLdDZhNKkNziqCnqFu1vwag@mail.gmail.com> (raw)
In-Reply-To: <CAMgjq7COo_-xJwXvy4sLjRHmb6VohMHub0TctS3M+gKwrfjPSg@mail.gmail.com>

On Mon, Feb 2, 2026 at 10:55 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> Right, then I think we need a Fixes tag, and is swap really the only
> victim of that change?

Good question. The comment in vmalloc.c mentions "some use
page->mapping, page->lru, etc." but I haven't found other concrete
examples that would hit this bug. Swap seems to be the only one
relying on page->private being zero.

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

You're right. Looking at swap_count_continued(), it already checks
page_private(head) != SWP_CONTINUED, not page_private(head) == 0.
The fix in swapfile.c should use the same condition in
add_swap_count_continuation():

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 46d2008e4b99..f131494d4262 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3859,10 +3859,11 @@ int add_swap_count_continuation(swp_entry_t
entry, gfp_t gfp_mask)

        spin_lock(&si->cont_lock);
        /*
-        * Page allocation does not initialize the page's lru field,
-        * but it does always reset its private field.
+        * Page allocation does not initialize the page's lru field, and
+        * vmalloc pages from split_page() may have stale page->private.
+        * Check for SWP_CONTINUED not just non-zero.
         */
-       if (!page_private(head)) {
+       if (page_private(head) != SWP_CONTINUED) {
                BUG_ON(count & COUNT_CONTINUED);
                INIT_LIST_HEAD(&head->lru);
                set_page_private(head, SWP_CONTINUED);

This handles both cases:
- page_private == 0 (normal fresh page)
- page_private == stale non-zero value (vmalloc split_page bug)

And the comment should be updated to reflect that vmalloc pages may
have stale page->private.
Should I send a v2 with this approach?

-- 
Best Regards,
Mike Gavrilov.


  reply	other threads:[~2026-02-02 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30 13:49 Mikhail Gavrilov
2026-01-30 13:59 ` Matthew Wilcox
2026-01-30 14:16   ` Mikhail Gavrilov
2026-01-30 15:30 ` Kairui Song
2026-01-30 15:47   ` Mikhail Gavrilov
2026-02-02  3:17     ` Kairui Song
2026-02-02  5:27       ` Mikhail Gavrilov
2026-02-02 17:54         ` Kairui Song
2026-02-02 20:21           ` Mikhail Gavrilov [this message]
2026-02-03  7:14             ` Mikhail Gavrilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABXGCsPPeKCqj4KB3Cp0r=rWd+0KLdDZhNKkNziqCnqFu1vwag@mail.gmail.com' \
    --to=mikhail.v.gavrilov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chrisl@kernel.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryncsn@gmail.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox