The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel
@ 2026-06-18 18:55 Sean Christopherson
  2026-06-19  4:51 ` Huang, Kai
  0 siblings, 1 reply; 3+ messages in thread
From: Sean Christopherson @ 2026-06-18 18:55 UTC (permalink / raw)
  To: Sean Christopherson, Paolo Bonzini; +Cc: kvm, linux-kernel

If KVM handles an I/O APIC EOI exit request with a bad vector, clamp the
vector to 255 and hope for the best instead of bugging the host.  In all
likelihood, a missed EOI is survivable for the guest, and it's most
definitely not remotely fatal to the host, i.e. potentially panicking the
host is completely unjustified.  Arbitrarily use 255 for the dummy vector,
the goal is purely to ensure the vector is covered by the bitmap.

Opportunistically ensure the EOI vector isn't negative, as it's a signed
integer, i.e. the "greater than 255" check won't guard against setting the
vector to a negative value (KVM uses -1 to say "no IRQ" in many flows).

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/x86.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d9d51803b7b2..fda09e03b960 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11212,7 +11212,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 		if (kvm_check_request(KVM_REQ_NMI, vcpu))
 			process_nmi(vcpu);
 		if (kvm_check_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu)) {
-			BUG_ON(vcpu->arch.pending_ioapic_eoi > 255);
+			if (WARN_ON_ONCE(vcpu->arch.pending_ioapic_eoi < 0 ||
+					 vcpu->arch.pending_ioapic_eoi > 255))
+				vcpu->arch.pending_ioapic_eoi = 255;
+
 			if (test_bit(vcpu->arch.pending_ioapic_eoi,
 				     vcpu->arch.ioapic_handled_vectors)) {
 				vcpu->run->exit_reason = KVM_EXIT_IOAPIC_EOI;

base-commit: 9d4853b044beefa21c4ee3e18c40653601a64ced
-- 
2.55.0.rc0.738.g0c8ab3ebcc-goog


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel
  2026-06-18 18:55 [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel Sean Christopherson
@ 2026-06-19  4:51 ` Huang, Kai
  2026-06-22 23:55   ` Sean Christopherson
  0 siblings, 1 reply; 3+ messages in thread
From: Huang, Kai @ 2026-06-19  4:51 UTC (permalink / raw)
  To: pbonzini@redhat.com, seanjc@google.com
  Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org

On Thu, 2026-06-18 at 11:55 -0700, Sean Christopherson wrote:
> If KVM handles an I/O APIC EOI exit request with a bad vector, clamp the
> vector to 255 and hope for the best instead of bugging the host.  In all
> likelihood, a missed EOI is survivable for the guest, and it's most
> definitely not remotely fatal to the host, i.e. potentially panicking the
> host is completely unjustified.  Arbitrarily use 255 for the dummy vector,
> the goal is purely to ensure the vector is covered by the bitmap.

255 is a valid vector.  How about use a CPU reserved one instead (e.g., vector
0) and hope for the best?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel
  2026-06-19  4:51 ` Huang, Kai
@ 2026-06-22 23:55   ` Sean Christopherson
  0 siblings, 0 replies; 3+ messages in thread
From: Sean Christopherson @ 2026-06-22 23:55 UTC (permalink / raw)
  To: Kai Huang
  Cc: pbonzini@redhat.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org

On Fri, Jun 19, 2026, Kai Huang wrote:
> On Thu, 2026-06-18 at 11:55 -0700, Sean Christopherson wrote:
> > If KVM handles an I/O APIC EOI exit request with a bad vector, clamp the
> > vector to 255 and hope for the best instead of bugging the host.  In all
> > likelihood, a missed EOI is survivable for the guest, and it's most
> > definitely not remotely fatal to the host, i.e. potentially panicking the
> > host is completely unjustified.  Arbitrarily use 255 for the dummy vector,
> > the goal is purely to ensure the vector is covered by the bitmap.
> 
> 255 is a valid vector.  How about use a CPU reserved one instead (e.g., vector
> 0) and hope for the best?

I was thinking it would be better to err on the side of spuriously exiting to
userspace, versus suppressing an exit?  And I wanted to keep the vector legal,
in case something else in KVM cares about legal vectors?  Hmm, but using 255 is
bad because it likely never be cleared, and thus will block other EOI exits due
to 255 being the highest priority vector.

Ah, and the field is never explicitly initialized beyond the structutre being,
so it's starting state is '0' as well.  My only hesitation with zero is that in
the unlikely case bit 0 is set in ioapic_handled_vectors, userspace will be extra
confused.  But that's easy enough to deal with, just skip the check.

This?

		if (kvm_check_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu)) {
			if (WARN_ON_ONCE(vcpu->arch.pending_ioapic_eoi < 0 ||
					 vcpu->arch.pending_ioapic_eoi > 255))
				vcpu->arch.pending_ioapic_eoi = 0;
			else if (test_bit(vcpu->arch.pending_ioapic_eoi,
					  vcpu->arch.ioapic_handled_vectors)) {
				vcpu->run->exit_reason = KVM_EXIT_IOAPIC_EOI;
				vcpu->run->eoi.vector =
						vcpu->arch.pending_ioapic_eoi;
				r = 0;
				goto out;
			}
		}


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-06-22 23:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-18 18:55 [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel Sean Christopherson
2026-06-19  4:51 ` Huang, Kai
2026-06-22 23:55   ` Sean Christopherson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox