All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: xuanqingshi <1356292400@qq.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode()
Date: Thu, 5 Mar 2026 07:33:04 -0800	[thread overview]
Message-ID: <aamiMBRsSwn7yxu0@google.com> (raw)
In-Reply-To: <tencent_4897299F3F479A188C8C19A7BD58D2A40608@qq.com>

On Thu, Mar 05, 2026, xuanqingshi wrote:
> kvm_apic_write_nodecode() dereferences vcpu->arch.apic without first
> checking whether the in-kernel LAPIC has been initialized.  If it has
> not (e.g. the vCPU was created without an in-kernel LAPIC), the
> dereference results in a NULL pointer access.
> 
> While APIC-write VM-Exits are not expected to occur on a vCPU without
> an in-kernel LAPIC, kvm_apic_write_nodecode() should be robust against
> such a scenario as a defense-in-depth measure, e.g. to guard against
> KVM bugs or CPU errata that could generate a spurious APIC-write
> VM-Exit.
> 
> Add a WARN_ON_ONCE() guard and bail early if vcpu->arch.apic is NULL.
> 
> Found by a VMCS-targeted fuzzer based on syzkaller.

Found how exactly?  If you managed to actually hit a NULL pointer deref here,
that *significantly* changes the value of adding defense in depth.

> Signed-off-by: xuanqingshi <1356292400@qq.com>
> ---
>  arch/x86/kvm/lapic.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 9381c58d4c85..0f9d314dfa2a 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2657,6 +2657,9 @@ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
>  {
>  	struct kvm_lapic *apic = vcpu->arch.apic;
>  
> +	if (WARN_ON_ONCE(!apic))
> +		return;

Hmm, a simple WARN isn't a net positive.  If the CPU generates a spurious APICv/AVIC
VM-Exit, or KVM managed to enable one or the other without an in-kernel local
APIC, then I'd *much* prefer a crash due to a NULL pointer dereference.  Letting
the vCPU continue on in this state would be disastrous for the guest.

But luckily we have KVM_BUG_ON().  And we can use lapic_in_kernel() to make this
"free" for the overwhelming majority of setups, which always use an in-kernel
local APIC (in which case lapic_in_kernel() is a static branch that returns true).

	if (KVM_BUG_ON(!lapic_in_kernel(vcpu), vcpu->kvm))
		return;

  reply	other threads:[~2026-03-05 15:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-05 11:07 [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode() xuanqingshi
2026-03-05 15:33 ` Sean Christopherson [this message]
2026-03-06  9:12   ` [PATCH v2] " xuanqingshi
2026-04-03 15:13     ` Sean Christopherson

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=aamiMBRsSwn7yxu0@google.com \
    --to=seanjc@google.com \
    --cc=1356292400@qq.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /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.