CVE-2026-98440: KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
We free the shadow S2 structures from kvmarchflushshadowall(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great.
Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have been destroyed already.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are likely affected?
The issue is in the Linux kernel's KVM arm64 nested-virtualization code, specifically its handling of shadow Stage-2 structures. Systems not using KVM on arm64 or not exercising this nested-virtualization path are not indicated by the provided information as exposed.
What condition triggers the unsafe cleanup?
The problematic behavior occurs when shadow Stage-2 structures are freed from kvm_arch_flush_shadow_all(). Those structures can still be referenced elsewhere, whereas the corrected cleanup defers destruction until the virtual machine is being torn down after its vCPUs have been destroyed.
How can I determine whether a fix is available in my kernel source?
The provided references identify the relevant stable-kernel commits: 876049f026b4dfaca0cc78ec81be0e639ca8525d, 22e82acec93a681071ed36f70eabe2d0c4e0bebd, and 5bf1c9175e657b3c2dc1cf77403031ac7aadcf66. Check whether your kernel source includes the applicable change or equivalent deferred destruction of the shadow S2 MMUs and their global array.