The vulnerability in kvm_vcpu_ioctl_interrupt() for LoongArch is a missing bounds check on the interrupt vector parameter — trivial to fix, but the real issue is what that missing check reveals about how KVM handles input validation across architectures.
The fix adds a simple bounds check. But this check isn't enforced at the KVM core level — every architecture must independently re-implement validation logic that exists in x86 and ARM implementations. When engineers port KVM to a new architecture, they're translating behavior under cognitive load focused on correctness, not cataloging every security assumption baked into the reference code. The missing check exists in x86 KVM; you only know to add it by reading that implementation. This is a port tax, not a review failure — the abstraction makes security-critical decisions implicit rather than enforced.
What should concern you: LoongArch KVM merged in Linux 6.1, roughly 18-24 months before this CVE. That window is where exposure accumulated invisibly. The CVSS of 8.8 reflects real severity — compromising the interrupt injection path means compromising the hypervisor boundary itself, a first-stage payload rather than terminal impact. The low EPSS is misleading. LoongArch deployment is small, but the systems running it are disproportionately high-value — research clusters, specialized infrastructure. Sophisticated attackers doing targeted reconnaissance of niche architectures won't show up in broad exploitation metrics.
Audit priority: don't just verify this patch is applied. Treat it as a signal that other LoongArch KVM ioctl paths likely have similar gaps. Map every userspace-reachable ioctl in the LoongArch KVM code and check each one against its x86/ARM counterpart for equivalent validation. The historical record shows that when one missing check is found, analogues exist elsewhere — ARM KVM had the same pattern in 2012, POWER followed, and each time the assumption was 'limited exposure, focused fix is sufficient.' Each time, subsequent audits found the same pattern recurring.
The process gap matters as much as the code gap. The commit that fixes this will read like any other bugfix. Future LoongArch KVM porters won't know it came from a userspace-reachable missing validation. Without a durable artifact — a bug tracker note, a maintainer reminder — the next new architecture hits the same blind spot. The kernel community has no mechanism to capture 'we missed this validation in the LoongArch port' as a systemic lesson. That should concern you more than the bounds check itself.