CRITICAL Introduced in 6.16
kvm VNCR Bypass
CVE-2026-89775
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
KernelScan AI9.2CRITICAL
01Description
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a "creative" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them.
02KernelScan AI Analysis
Risk summary
A guest VM running on an arm64 host with KVM nested virtualization can cause TLB invalidation to silently fail when the stage-1 MMU is disabled, leaving stale TLB entries that grant access to physical pages the host may have repurposed. This can lead to cross-tenant or guest-to-host memory disclosure and corruption. Any deployment running untrusted VMs with nested virtualization enabled is at risk.
Vulnerability analysis
When a guest VM disables its stage-1 MMU, KVM arm64 records this state using a special negative walk level. The code that converts the page granule size and walk level into a TLB type code does not handle negative levels — it casts the value to an unsigned byte and masks the bottom two bits, producing an incorrect result that yields a TLB invalidation range of zero. Consequently, no TLB entries are actually invalidated, and stale mappings persist in the TLB. A malicious guest can then continue accessing physical pages that the host has invalidated and potentially repurposed for another guest or for the host itself, leading to cross-tenant or guest-to-host memory disclosure and corruption. The fix makes the conversion code detect negative levels and return a fallback value, and makes the size lookup return a conservative 1 GB default when no valid TLB type code is present, ensuring invalidation always covers a meaningful range. A guest VM on an arm64 host with nested virtualization enabled can trigger this through ordinary TLB invalidation operations.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 6.16 | 6.18.51 | be54a70067c7 |
| 7.2 | 6.16 | 7.2.5 | 1c9fca34b962 |
| mainline | 6.16 | 7.3-rc1 | 8053393680d4 |