Re: [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel

[Sean Christopherson <seanjc@google.com>]

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;
			}
		}