On Wed, Sep 02, 2026 at 12:22:09PM +0000, [email protected] wrote: > [Severity: High] > This is a pre-existing issue, but does this new assertion trigger test > failures due to how __get_sregs() handles the interrupt_bitmap?
No. Neither of the two tests that reach compare_sregs(), req_and_verify_all_valid and set_and_verify_various, ever injects an interrupt: the guest just loops on an IN from a port, and nothing in the test writes interrupt_bitmap. KVM allocates the kvm_run page with __GFP_ZERO, so the sync region's copy starts out zero and stays zero, and the KVM_GET_SREGS side is filled from a kzalloc()'d buffer. Both sides are all zeros at every point where the memcmp() runs, which I confirmed by printing them, and the series passes 10/10 on an AMD host. > This function sets the bit corresponding to the currently injected interrupt > but never clears the prior contents of the array. That part is right, and it is observable from userspace. Planting a bit in the sync region and running the vCPU with KVM_SYNC_X86_SREGS in kvm_valid_regs but nothing in kvm_dirty_regs: run->s.regs.sregs.interrupt_bitmap[0] = 1ULL << 0x30; leaves KVM_GET_SREGS reporting 0x0 while the sync region still reads 0x1000000000000 after the exit. KVM refreshed sregs there and left the caller's bit in place. > Could this lead to spurious interrupt injections or corrupted state during > live migration for any VMM using the KVM_SYNC_X86_SREGS API? Handing that same stale bit back with KVM_SYNC_X86_SREGS set in kvm_dirty_regs does inject it: __set_sregs()'s find_first_bit() picks up vector 0x30, kvm_queue_interrupt() queues it, and the guest dies on an unhandled 0x30. So a VMM that read-modify-writes the sync region can resubmit a vector KVM itself put there on an earlier exit, since nothing clears the field once a bit is set. I could not demonstrate KVM planting the bit itself here, as selftest VMs have an in-kernel irqchip and KVM_INTERRUPT returns -ENXIO; that half rests on __get_sregs() only ever doing set_bit(). Whether KVM should zero interrupt_bitmap before it ORs in the injected vector, or clear it in store_regs(), is an ABI question rather than something this test change should decide, and I am happy to send a patch if that is the direction. I would keep the memcmp() either way: it is precisely the check that would catch a stale bit turning up in the sync region. Thanks, Hemanth
