Re: [PATCH] mm/rmap: don't discard lazyfree THPs at PMD level

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Mon, Oct 12, 2026 at 04:37:34PM -0400, Zi Yan wrote:
> On 12 Oct 2026, at 11:22, Lorenzo Stoakes (ARM) wrote:
>
> > On Mon, Oct 12, 2026 at 10:33:34AM -0400, Zi Yan wrote:

> > }
>
> Yes.
>
> My wording was not precise.
>
> zap_pmd_range() doesn’t take the PTL since it sees pmd_none(), while
> try_to_unmap_one() takes the PTL.

Yeah, this is nasty.

No wonder it took some AI analysis to find this :)

> > That bit isn't special to MREMAP_DONTUNMAP.
>
> Right.

But it is a 'very special' flag for mremap... :)

The # of bugs that thing has produced...

> > That set pmd could also UAF on the PMD page table in theory couldn't it?
>
> No, in __discard_anon_folio_pmd_locked(), the caller holds anon_vma read lock;
> when mremap() or munmap() calls free_pgtables() to get rid of page tables,
> they first call unlink_anon_vmas() and get blocked by the aforementioned read
> lock. set_pmd_at() is called while free_pgtables() is blocked, so no UAF here.

Ah ok thanks. Yeah the rmap lock is held throughout that.

Hey - when I eliminate the rmap lock things are going to be even more fun ;)

>
> >
> > It's all really horrible.
>
> And kills my brain.

Yeah this hurt my head too.

I actually (rare in 2026) only got AI to chime in late in my analysis, and while
it helped confirm/deny some stuff it wasn't even that helpful in avoiding the
head... f..un.

> >>> So unmap_vmas() doesn't correctly populate the mmu_gather struct for the
> >>> range, meaning that the underlying page isn't freed and the refcount,
> >>> mapcount etc. are all left as they were?
> >>
> >> Yes to the underlying page isn’t freed.
> >
> > The refcount and mapcount etc. would be correct? I think the refcount would be
> > such that it permanently leaks and the mapcount would be incorrect or only
> > accidentally correct?
>
> refcount and mapcount would be wrong in the munmap case. Both are correct
> in MREMAP_DONTUNMAP case, since the folio is still mapped in the source VMA
> but its anon_vma says it belongs to dst VMA. When dst VMA is unmapped,
> the anon_vma is freed, but the folio is still mapped and its ->mapping
> points to a freed anon_vma. A rmap code checking folio->mapping is a UAF.

OK I _think_ you can only have a destination that either has the same anon_vma
or is unfaulted (so gets given the source anon_vma) so yeah, the anon_vma is
still right but is pointing at the destination VMA, while still being mapped in
the source one :)))

MREMAP_DONTUNMAP really is the gift that keeps on giving.

> > They seem like they are existing bugs effectively in pmdp_invalidate()? Or stuff
> > that we would want to fix anyway I guess?
>
> SPARC’s thp_pte_count might cause other issues, since its code only considers
> huge pmd splitting. powerpc’s page table check might have an issue.

Such fun... lord.

> >> I can remove the dead code if you think that is better.
> >
> > No, if you plan to reinstate it (soon!) then that's fine, but please
> > explain that you're intentionally doing that in the commit message please!
>
> Sure. I will try to come up with a concise but comprehensive message to cover
> both the issue and why pmdp_invalidate() does not work itself.

Great thanks, I saw the v2 and it all LGTM!

--
Cheers, Lorenzo