This vulnerability exposes a fundamental design flaw in KVM arm64's nested virtualization path, not a simple missing check. The VNCR (Virtual Nested Control Register) mapping code uses guest-stage-1 permissions as the sole determinant for whether a memory region is writable at the host level, without ever verifying that the underlying physical page frame (PFN) actually permits writes. This works silently for writable memslots but fails for read-only memslots, allowing a nested L2 guest to corrupt memory the hypervisor believes is protected.
The vulnerability requires a specific configuration: arm64, nested virtualization enabled, read-only memory slots in use, and a write sequence from L2. The exploit surface is narrower than the CVSS 9.1 suggests — this isn't a general privilege escalation. However, the blast radius within that narrow scope is severe: L2 can corrupt memory that L1's security model declares inaccessible, undermining the isolation contract of nested virtualization entirely. Additionally, the early return path for read-only PFNs introduced a page leak, compounding the security failure with a resource exhaustion vector.
The fix involves caching writability at a different abstraction layer and promoting resulting faults to a Stage-2 Exception Abort (SEA) — architecturally sound but representing a retroactive adjustment to an abstraction that was never formally defined.
What should concern you: this is not an isolated instance. The pattern of trusting guest-managed permissions as a security boundary has generated multiple CVEs across hypervisors (KVM x86 CVE-2017-12154, CVE-2020-10702). The arm64 nested path is a new instantiation of an old failure mode. Audit your codebase for other paths where guest-stage-1 state is used as a proxy for host-level constraints without independent PFN verification — particularly in non-nested arm64 code paths, which may carry the same assumption in less-examined corners.