* [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode()
@ 2026-03-05 11:07 xuanqingshi
2026-03-05 15:33 ` Sean Christopherson
0 siblings, 1 reply; 3+ messages in thread
From: xuanqingshi @ 2026-03-05 11:07 UTC (permalink / raw)
To: seanjc, pbonzini; +Cc: kvm, linux-kernel, xuanqingshi
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.
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;
+
/*
* ICR is a single 64-bit register when x2APIC is enabled, all others
* registers hold 32-bit values. For legacy xAPIC, ICR writes need to
--
2.25.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode()
2026-03-05 11:07 [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode() xuanqingshi
@ 2026-03-05 15:33 ` Sean Christopherson
2026-03-06 9:12 ` [PATCH v2] " xuanqingshi
0 siblings, 1 reply; 3+ messages in thread
From: Sean Christopherson @ 2026-03-05 15:33 UTC (permalink / raw)
To: xuanqingshi; +Cc: pbonzini, kvm, linux-kernel
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;
^ permalink raw reply [flat|nested] 3+ messages in thread* [PATCH v2] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode()
2026-03-05 15:33 ` Sean Christopherson
@ 2026-03-06 9:12 ` xuanqingshi
0 siblings, 0 replies; 3+ messages in thread
From: xuanqingshi @ 2026-03-06 9:12 UTC (permalink / raw)
To: seanjc, pbonzini; +Cc: kvm, linux-kernel, xuanqingshi
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.
Use KVM_BUG_ON() with lapic_in_kernel() instead of a simple
WARN_ON_ONCE(), as suggested by Sean Christopherson, so that KVM
kills the VM outright rather than letting it continue in a broken
state.
Found by a VMCS-targeted fuzzer based on syzkaller.
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..02f2039d5f99 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 (KVM_BUG_ON(!lapic_in_kernel(vcpu), vcpu->kvm))
+ return;
+
/*
* ICR is a single 64-bit register when x2APIC is enabled, all others
* registers hold 32-bit values. For legacy xAPIC, ICR writes need to
--
2.25.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-03-06 9:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-05 11:07 [PATCH] KVM: x86: Add LAPIC guard in kvm_apic_write_nodecode() xuanqingshi
2026-03-05 15:33 ` Sean Christopherson
2026-03-06 9:12 ` [PATCH v2] " xuanqingshi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox