CVE-2026-89775: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation

Published Sep 16, 2026
·
Updated

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 (S1MMUDISABLED).

This ends-up being misinterpreted by pgshiftleveltottl() 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 pgshiftleveltottl() to handle these negative levels, and ttltosize() to always return SZ1G 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 S1MMUDISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them.

Affected Software

1 affected component
Linux Kernel

Event History

Sep 16, 2026
CVE Published
via MITRE·08:39 AM
Data Sourced
via MITRE·08:39 AM
Description

Frequently Asked Questions

1

Under what condition does the incorrect TLB invalidation size occur?

It occurs when KVM on arm64 evaluates a Stage-1 mapping such as VNCR while the Stage-1 MMU is disabled. That state is represented by a negative walk level, which was misinterpreted during TTL calculation.

2

What is the practical effect of the flawed calculation?

The invalidation size can be calculated as 0 rather than covering the appropriate mapping size. The fix makes negative levels take the no-valid-TTL path and uses a 1 GiB size.

3

How can I determine whether a kernel includes the fix?

Check whether the kernel contains the stable changes referenced by commit IDs be54a70067c7dbe1381157e8a238fa4b16ea9c05, 1c9fca34b9625a67a7f1a03c8604f3df760c6c49, or 8053393680d4fa3eb962667d2be95dd39f0940e5.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203