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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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?