CVE-2026-72295 is a missing bounds check in LoongArch KVM's irqfd routing path. The vulnerability allows an out-of-bounds kernel write when processing irqchip configuration — a theoretical kernel write primitive that earned a CVSS of 8.8. The EPSS score of 0.00161 tells a different story: LoongArch hardware has negligible production deployment, and exploitation requires an attacker who already has sufficient KVM access to configure irqfd routing. The actual attack surface is narrow enough that this CVE's practical risk is minimal despite the severity score.
The patch adds a bounds check before indexing into the routing table's chip array. That's straightforward. What's more interesting is what this bug reveals about how new architecture support gets added to the kernel. LoongArch KVM support landed years after x86 and ARM had been thoroughly fuzzed, yet a basic missing input validation slipped through — not because LoongArch developers were negligent, but because the review process for new architecture ports compares against what compiles and boots, not against the accumulated CVE history of other architectures.
Here's what you should actually do with this information: don't lose sleep over LoongArch KVM in production. Instead, use this as a lens to audit other relatively new KVM ports — particularly RISC-V and ARM's newer PSCI paths. The validation pattern that was missing here (bounds check before array indexing in routing) has appeared in multiple architecture transitions before. Check whether equivalent array-access paths in those implementations have corresponding bounds validation that exists in x86 or ARM. If the pattern repeats, you're looking at a class of vulnerability that gets missed systematically during upstreaming, not an isolated LoongArch bug.