All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: David Lee <david.lee@trailofbits.com>
Cc: pbonzini@redhat.com, Kyle Zeng <kylebot@openai.com>,
	 "Dominik 'Disconnect3d' Czarnota"
	<dominik.czarnota@trailofbits.com>,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,  David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] KVM: pfncache: track all MMU notifier invalidations
Date: Tue, 11 Aug 2026 07:40:07 -0700	[thread overview]
Message-ID: <ans0RzGmObCkAb6e@google.com> (raw)
In-Reply-To: <20260810152730.841260-1-david.lee@trailofbits.com>

+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!

  reply	other threads:[~2026-08-11 14:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 15:27 [PATCH] KVM: pfncache: track all MMU notifier invalidations David Lee
2026-08-11 14:40 ` Sean Christopherson [this message]
2026-08-11 17:16   ` David Lee
2026-08-11 17:41     ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ans0RzGmObCkAb6e@google.com \
    --to=seanjc@google.com \
    --cc=david.lee@trailofbits.com \
    --cc=dominik.czarnota@trailofbits.com \
    --cc=dwmw2@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=kylebot@openai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.