CVE-2026-89917: KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Handle VNCR TLB invalidation race with vcpuput() VNCR unmapping
While VNCR TLB invalidation always occurs under the MMU lock, vcpuput() doesn't, while it unmaps the VNCR page.
The problem is that the invalidation evaluates vncrtlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, thiscpuresetvncrfixmap() unconditionally unmaps if L1VNCRMAPPED is set.
These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUGON() on the vcpuput() path. And the two can end-up calling vncrfixmap(-1), with extra lethal effects.
Move the reset of vncrtlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpuput() still need to unconditionally unmap the current VNCR to close another ugly race.
Finally, the assignment of vncrtlb::cpu is moved to be kept in sync with the actual mapping, similar to L1VNCRMAPPED being set.
Event History
Frequently Asked Questions
What runtime conditions are involved in triggering the race?
The race requires concurrent VNCR TLB invalidation and vcpu_put() activity that unmaps a VNCR page. TLB invalidation runs under the MMU lock, but vcpu_put() does not, allowing the mapping state to be checked and changed concurrently.
What is the observable impact if the race occurs?
The race can trigger a BUG_ON() on the vcpu_put() path. Both racing paths can also invoke vncr_fixmap(-1), which is described as having additional lethal effects.