Re: Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

[Jann Horn <jannh@google.com>]

On Fri, Oct 24, 2025 at 9:59 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
> On Fri, Oct 24, 2025 at 09:43:43PM +0200, Jann Horn wrote:
> > > So my question is - would it be reasonable to consider this at the very
> > > least a vanishingly small, 'paranoid' fixup? I think it's telling you
> > > couldn't come up with a repro, and you are usually very good at that :)
> >
> > I mean, how hard this is to hit probably partly depends on what
> > choices hypervisors make about vCPU scheduling. And it would probably
> > also be easier to hit for an attacker with CAP_PERFMON, though that's
> > true of many bugs.
> >
> > But yeah, it's not the kind of bug I would choose to target if I
> > wanted to write an exploit and had a larger selection of bugs to
> > choose from.
> >
> > > Another question, perhaps silly one, is - what is the attack scenario here?
> > > I'm not so familiar with hugetlb page table sharing, but is it in any way
> > > feasible that you'd access another process's mappings? If not, the attack
> > > scenario is that you end up accidentally accessing some other part of the
> > > process's memory (which doesn't seem so bad right?).
> >
> > I think the impact would be P2 being able to read/write unrelated data
> > in P1. Though with the way things are currently implemented, I think
> > that requires P1 to do this weird unmap of half of a hugetlb mapping.
> >
> > We're also playing with fire because if P2 is walking page tables of
> > P1 while P1 is concurrently freeing page tables, normal TLB flush IPIs
> > issued by P1 wouldn't be sent to P2. I think that's not exploitable in
> > the current implementation because CONFIG_MMU_GATHER_RCU_TABLE_FREE
> > unconditionally either frees page tables through RCU or does IPI
> > broadcasts sent to the whole system, but it is scary because
> > sensible-looking optimizations could turn this into a user-to-kernel
> > privilege escalation bug. For example, if we decided that in cases
> > where we already did an IPI-based TLB flush, or in cases where we are
> > single-threaded, we don't need to free page tables with Semi-RCU delay
> > to synchronize against gup_fast().
>
> Would it therefore be reasonable to say that this is more of a preventative
> measure against future kernel changes (which otherwise seem reasonable)
> which might lead to exploitable bugs rather than being a practiclaly
> exploitable bug in itself?

I would say it is a security fix for theoretical userspace that either
intentionally partially unmaps hugetlb mappings (which would probably
be weird), or maps and partially unmaps attacker-supplied file
descriptors (without necessarily expecting them to be hugetlb). (I
know of userspace that mmap()s file descriptors coming from untrusted
code, though I don't know examples that would then partially unmap
them.) Admittedly there is some perfectionism involved here on my
part. In particular, it irks me to make qualitative distinctions
between bugs based on how hard to hit the timing requirements for them
are.

But yes, a large part of my motivation for writing this patch was to
prevent reasonable future changes to the rest of MM from making this a
worse bug.