* Re: [BUG] KVM: x86/xen: gfn_to_pfn_cache left active after mmu_notifier release leads to a host use-after-free write
[not found] <atolq8545YGo4iKx@google.com>
@ 2026-10-31 9:05 ` Amirmohammad Eftekhar
0 siblings, 0 replies; only message in thread
From: Amirmohammad Eftekhar @ 2026-10-31 9:05 UTC (permalink / raw)
To: seanjc, dwmw2
Cc: w, paul, pbonzini, kvm, linux-kernel, amirmohammad.eftekhar,
amirmohammadeftekhar
On Thu, Oct 22, 2026, Sean Christopherson wrote:
> Anyone object to taking this on-list?
No objection, please do, and thanks for picking it up.
> I'm pretty sure this should go inside kvm_flush_shadow_all() [...]
> The other wrinkle is that super strictly speaking the invalidation needs to
> happen before kvm_arch_guest_memory_reclaimed().
Agreed on both, and the comment can go.
Putting it in kvm_flush_shadow_all() is also right for a reason beyond the
mmu_notifier point: the stale cache at release is not Xen-specific. The KVM
pvclock cache (vcpu->arch.pv_time, arch/x86/kvm/x86.c) is left active and valid
across release in exactly the same way. It just is not a use-after-free write
today, because once the owning task is gone nothing writes it asynchronously,
whereas the Xen event-channel hrtimer does. So the Xen timer is the only
reachable writer at the moment, but the dangling-cache condition is generic,
and invalidating in kvm_flush_shadow_all() covers both.
> Rather than pass literal numbers, what if (over a few patches) we massage
> gfn_to_pfn_cache_invalidate_start() to take a range pointer [...]
and David wrote:
> I think I'd be slightly more inclined just to add a parallel
> gfn_to_pfn_cache_invalidate_all() which can be a whole lot *simpler*
> than the existing range-based one [...]
Either shape is fine by me. The one practical difference is the backport: the
standalone gfn_to_pfn_cache_invalidate_all() is a small self-contained change
that is easy to send to stable, while the range-pointer rework is nicer
long-term but more churn to carry back. I am happy to follow whichever you two
prefer.
I can turn this into a proper series and add the reproducer as a KVM selftest
(the UAF reproduces under KASAN through the Xen timer, write into the freed
shinfo page), or just test your version if you would rather carry it. Let me
know which you prefer.
Dropping stable@ and security@ from Cc, per Willy.
Thanks,
Amirmohammad
^ permalink raw reply [flat|nested] only message in thread