KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.18.51, 7.2.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The vulnerability affects the Linux kernel's KVM hypervisor on arm64 systems, specifically its handling of VNCR (virtual nested control register) translations used for nested virtualization. A race between vCPUs can let the hypervisor cache a stale address translation after the guest has invalidated it, potentially allowing a guest to access memory it should no longer be able to reach.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: • vcpu A walks the PTs to translate VNCR • before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA • vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 · fixed in d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd; From 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 · fixed in 11ee3faab4f1755d126bead9f882e75a7a677860; From 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 · fixed in 2b7324f3a0c1072b9d578b8d42f199506753f26e
- Linux Linux
6.16
- KernelLinux
From 6.16.0 · fixed in 6.18.51; From 6.19.0 · fixed in 7.2.5