From: Kyle Zeng <kylebot@openai.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Rik van Riel <riel@surriel.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Harry Yoo <harry@kernel.org>,
Jann Horn <jannh@google.com>, Lance Yang <lance.yang@linux.dev>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs
Date: Thu, 15 Oct 2026 19:56:38 -0700 [thread overview]
Message-ID: <atGSZkBHtsnJ4k1A@com-75606> (raw)
In-Reply-To: <20261015192020.5336a49bc516219e8254dfdf@linux-foundation.org>
On Thu, Oct 15, 2026 at 07:20:20PM -0700, Andrew Morton wrote:
> On Thu, 15 Oct 2026 18:15:49 -0700 Kyle Zeng <kylebot@openai.com> wrote:
>
> > A PTE-mapped large folio can straddle PMD boundaries after an unaligned
> > mremap(). If the first part is discarded and replaced with an unrelated
> > huge PMD, page_vma_mapped_walk() stops instead of looking for the rest
> > of the folio in subsequent PMDs.
> >
> > This also affects migration entries. A walk that stops at an unrelated
> > huge PMD can leave migration PTEs behind when migration or an anonymous
> > folio split restores the mappings. Those entries do not hold mapping
> > references and can outlive the source folio.
> >
> > Skip the current PMD rather than ending the walk on a flag or PFN
> > mismatch. Do the same if the PMD became nonpresent before the locked
> > recheck. Release the PMD lock, clear the per-PMD state and advance with
> > step_forward(), so the existing range limit controls termination.
> > This covers present, migration and device-private huge PMDs while
> > preserving the matching-PMD and split-to-PTE paths.
>
> As always, when fixing a bug please describe the worst-case
> userspace-visible effects of the bug.
>
> I asked $LLM and was told
>
> : The worst credible effects are permanent application hangs, kernel
> : crashes, and potentially system-wide denial of service. Stale
> : migration entries can refer to freed and reused physical pages, causing
> : page faults to access unrelated folio metadata. Memory corruption is
> : possible but unproven; cross-process information disclosure has not
> : been established.
>
> But you have an LLM too! So please never again send a bugfix without
> this info.
>
> Also please explain whether there's a reproducer and if so, at least
> describe it and confirm the before-and-after results.
>
> Thanks.
>
Hi Andrew,
This issue can lead to memory corruption and I have a reproducer for it.
I can update the description and send in a v2 if you think it is proper.
Best,
Kyle
next prev parent reply other threads:[~2026-10-16 2:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 1:15 [PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs Kyle Zeng
2026-10-16 2:20 ` Andrew Morton
2026-10-16 2:56 ` Kyle Zeng [this message]
2026-10-16 7:46 ` David Hildenbrand (Arm)
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=atGSZkBHtsnJ4k1A@com-75606 \
--to=kylebot@openai.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=riel@surriel.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.