CVE-2026-72278

The CVSS 9.3 rating on this CVE is technically accurate but practically misleading for most environments. The vulnerability is a TLB coherency problem specific to VNCR (Virtual Nested Context Register) handling in KVM/arm64 nested virtualization. When a guest first reads from VNCR before writing to it, the initial translation establishes a read-only mapping. When the subsequent write arrives, KVM attempts to fault with FOLL_WRITE against an already read-only PFN, creating a mismatch that prevents proper write access. The fix pattern—TLB invalidation followed by translation re-fetch—is textbook cache coherency reconciliation, and the mention of FEAT_ETS2/3 ordering requirements confirms this sits at the intersection of architecture-specific memory ordering guarantees and the hypervisor's internal page table management. The VNCR abstraction is the real vulnerability here. It leaks hardware-level coherency concerns that developers shouldn't have to reason about—the read-before-write sequence isn't exotic guest behavior, it's a natural consequence of how guests initialize structures. The fact that KVM doesn't handle this idempotently, and instead requires explicit TLB invalidation and retry logic, is a systems design failure. This isn't the first VNCR coherency problem and it won't be the last: each FEAT_* extension added to the nested surface creates new translation paths that interact with stage-2 fault handling in ways the existing code didn't anticipate. The TLB flush-and-retry pattern appearing repeatedly is technical debt being serviced, not robust design. For defenders: the question isn't whether CVSS is the right metric—it's whether your environment uses KVM/arm64 nested virtualization at all. If you don't run nested virt, this is academic. If you do run it in multi-tenant cloud environments, this is a priority patch despite the narrow trigger conditions, because successful exploitation means a malicious tenant escapes to the hypervisor layer and potentially compromises every VM on that host. The EPSS score of 0.00194 captures exploitability probability today, not the exposure window that opens the moment this CVE is published. Once disclosed, rational attackers will stockpile this precisely because the trigger is narrow but the strategic value in multi-tenant environments is high. The severity conversation should center on exposure assessment, not base scores.

Reviewed through automated stages and approved by a human before publication.