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?