Re: [PATCH] KVM: pfncache: track all MMU notifier invalidations

On 11 August 2026 18:16:58 BST, David Lee <[email protected]> wrote:
>Hi Sean,
>
>Please refer to the attached reproducer.
>
>Required configuration:
>* CONFIG_KVM
>* CONFIG_KVM_XEN
>* An x86 KVM host
>
>CONFIG_KASAN is not required for the vulnerability, but it is used to
>produce the attached diagnostic output.
>
>========== Reproduction ==========
>Step 1: Build and boot an affected x86 kernel with CONFIG_KVM,
>CONFIG_KVM_XEN, and CONFIG_KASAN enabled.
>
>The confirmed kernel source revision is:
>
>~
>a13c140cc289c0b7b3770bce5b3ad42ab35074aa
>~
>
>Step 2: Compile the attached `poc.c`:
>
>~
>gcc -static -O2 -Wall -Wextra -pthread -o poc poc.c
>~
>
>Step 3: Run the PoC as a non-root user that has permission to open
>`/dev/kvm`:
>
>~
>./poc
>~
>
>The PoC creates a KVM VM without any memslots, maps one anonymous page,
>and runs two threads on separate CPUs. One thread repeatedly activates
>and deactivates the Xen shared-info HVA cache. The other repeatedly
>discards the backing page with `MADV_DONTNEED`.
>
>The race is timing-dependent. The supplied PoC runs for 90 seconds. On
>the confirmed test system it produced the attached KASAN report in
>`splash.txt`.
>
>Best regards,
>David
>
>On Tue, Aug 11, 2026 at 10:40 AM Sean Christopherson <[email protected]>
>wrote:
>
>> +David W
>>
>> On Mon, Aug 10, 2026, David Lee wrote:
>> > From: Kyle Zeng <[email protected]>
>> >
>> > There is a race condition in KVM's gfn-to-pfn cache refresh and MMU
>> > notifier handling. An HVA-backed cache can publish a stale PFN and
>> > kernel virtual address after the corresponding userspace mapping has
>> > been invalidated. The Xen shared-info HVA interface immediately reads
>> > and writes through that stale address, resulting in a host-kernel
>> > use-after-free.
>> >
>> > The cache refresh path in virt/kvm/pfncache.c drops gpc->lock while
>> > resolving and mapping an HVA. It uses mn_active_invalidate_count and
>> > mmu_invalidate_seq to detect an MMU notifier interval that overlaps
>> > this unlocked window. However, mmu_invalidate_seq is advanced only
>> > when the invalidated HVA overlaps a KVM memslot. HVA-backed caches are
>> > explicitly allowed to refer to memory outside all memslots. If such an
>> > invalidation starts and finishes while gpc->valid is false, the active
>> > count returns to zero without a sequence change and the refresh accepts
>> > a stale PFN.
>> >
>> > An unprivileged process with access to /dev/kvm can reach this path with
>> > KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA. KASAN-detected use-after-free in
>> > kvm_xen_shared_info_init(). The affected function reads and writes Xen
>> > wall-clock fields through the stale mapping, so the issue can cause a
>> > host-kernel crash and memory corruption.
>> >
>> > The attached KASAN output confirms:
>> >
>> >   BUG: KASAN: use-after-free in kvm_xen_shared_info_init+0x344/0x3d0
>> [kvm]
>> >   Read of size 4 at addr ffff888046000900 by task poc/1266
>> >
>> > Add a notifier-specific sequence that advances for every completed
>> > invalidate interval before mn_active_invalidate_count is decremented,
>> > and use that sequence for pfncache retry. The existing barrier pairing
>> > then guarantees refresh observes either an active invalidation or a
>> > sequence change.
>> >
>> > Fixes: 721f5b0dda78 ("KVM: pfncache: allow a cache to be activated with
>> a fixed (userspace) HVA")
>> > Cc: [email protected] # 6.9+
>> > Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
>> > Signed-off-by: Kyle Zeng <[email protected]>
>> > Co-developed-by: David Lee <[email protected]>
>> > Signed-off-by: David Lee <[email protected]>
>> > ---
>> > Bug found and triaged by OpenAI Security Research and
>> > validated by Trail of Bits.
>> >
>> > Trail of Bits has a reproducer for this bug that triggers a
>> > KASAN use-after-free and can share if needed.
>>
>> Go ahead and share, syzbot has been reporting this race for some time,
>> i.e. how
>> to repro this isn't exactly a secret, and the more testcases the better.
>> This is
>> also like the fourth or fifth proposed fix for the bug (bugs?).  I think
>> the most
>> recent version of the fix we are pursuing is here:
>>
>> https://lore.kernel.org/all/[email protected]
>>
>> Thanks!
>>

Thanks. Sounds very much like the reproducers I've been running many times in parallel on my test hosts since Friday, testing various iterations of what is now in my xen-srcu-prealloc branch. But I can add it to the stable...