linux-kernel - [PATCH 2/9] KVM: x86: Drop guest/user-triggerable asserts on IRR/ISR vectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251206004311.479939-3-seanjc@google.com>
Date: Fri,  5 Dec 2025 16:43:04 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>, David Woodhouse <dwmw2@...radead.org>, Paul Durrant <paul@....org>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 2/9] KVM: x86: Drop guest/user-triggerable asserts on IRR/ISR vectors

Remove the ASSERT()s in apic_find_highest_i{r,s}r() that exist to detect
illegal vectors (0-15 are reserved and never recognized by the local APIC),
as the asserts, if they were ever to be enabled by #defining DEBUG, can be
trivially triggered from both the guest and from userspace, and ultimately
because the ASSERT()s are useless.

In large part due to lack of emulation for the Error Status Register and
its "delayed" read semantics, KVM doesn't filter out bad IRQs (IPIs or
otherwise) when IRQs are sent or received.  Instead, probably by dumb
luck on KVM's part, KVM effectively ignores pending illegal vectors in
the IRR due vector 0-15 having priority '0', and thus never being higher
priority than PPR.

As for ISR, a misbehaving userspace could stuff illegal vector bits, but
again the end result is mostly benign (aside from userspace likely
breaking the VM), as processing illegal vectors "works" and doesn't cause
functional problems.

Regardless of the safety and correctness of KVM's illegal vector handling,
one thing is for certain: the ASSERT()s have done absolutely nothing to
help detect such issues since they were added 18+ years ago by commit
97222cc83163 ("KVM: Emulate local APIC in kernel").

For all intents and purposes, no functional change intended.

Signed-off-by: Sean Christopherson <seanjc@...gle.com>
---
 arch/x86/kvm/lapic.c | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 558adcb67171..785c0352fa0e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -666,8 +666,6 @@ static inline int apic_search_irr(struct kvm_lapic *apic)

 static inline int apic_find_highest_irr(struct kvm_lapic *apic)
 {
-	int result;
-
 	/*
 	 * Note that irr_pending is just a hint. It will be always
 	 * true with virtual interrupt delivery enabled.
@@ -675,10 +673,7 @@ static inline int apic_find_highest_irr(struct kvm_lapic *apic)
 	if (!apic->irr_pending)
 		return -1;

-	result = apic_search_irr(apic);
-	ASSERT(result == -1 || result >= 16);
-
-	return result;
+	return apic_search_irr(apic);
 }

 static inline void apic_clear_irr(int vec, struct kvm_lapic *apic)
@@ -731,8 +726,6 @@ static inline void apic_set_isr(int vec, struct kvm_lapic *apic)

 static inline int apic_find_highest_isr(struct kvm_lapic *apic)
 {
-	int result;
-
 	/*
 	 * Note that isr_count is always 1, and highest_isr_cache
 	 * is always -1, with APIC virtualization enabled.
@@ -742,10 +735,7 @@ static inline int apic_find_highest_isr(struct kvm_lapic *apic)
 	if (likely(apic->highest_isr_cache != -1))
 		return apic->highest_isr_cache;

-	result = apic_find_highest_vector(apic->regs + APIC_ISR);
-	ASSERT(result == -1 || result >= 16);
-
-	return result;
+	return apic_find_highest_vector(apic->regs + APIC_ISR);
 }

 static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
-- 
2.52.0.223.gf5cc29aaa4-goog