CVE-2026-46317

What it actually does

This is a use-after-free race condition in the Linux kernel KVM implementation for arm64 nested virtualization. The nested_mmus array can be reallocated and freed while another kernel path walks it under the MMU lock, including through MMU notifier handling. A local user with access to KVM functionality could potentially trigger the race from a guest/virtualization context, causing the kernel to dereference freed memory. Successful exploitation could lead to kernel memory corruption with confidentiality, integrity, and availability impact, including potential local privilege escalation or host kernel crash.

Why it matters to the business

Systems running affected Linux kernels with KVM on arm64 are at risk if untrusted or lower-privileged users can create or control virtual machines. The most likely operational impact is host instability or denial of service, but the CVSS profile indicates that compromise of the virtualization host is also possible. The issue is not currently listed in CISA KEV, is not identified as ransomware-used, and has a low EPSS score, so broad active exploitation is not indicated; however, virtualization hosts are high-value assets and should be patched through normal-to-expedited kernel maintenance windows.

How an attack unfolds

An attacker first needs local access with permission to interact with KVM, typically by launching or controlling a virtual machine on an arm64 host where nested virtualization paths are reachable. The attacker then attempts to create timing pressure between nested MMU initialization/reallocation and MMU notifier activity that walks the nested_mmus array. If the race is won, the kernel may access memory after it has been freed. Depending on allocator behavior and memory reuse, this can result in a kernel crash or controlled memory corruption. A reliable exploit would likely require repeated attempts, careful heap shaping, and knowledge of the target kernel build and hardening configuration.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the KVM arm64 nested_mmus locking issue. Because no product-specific fixed versions were provided, track the fix through the relevant Linux distribution, appliance vendor, cloud image, or kernel stable branch advisories. Prioritize arm64 virtualization hosts and systems where untrusted users, tenants, CI jobs, containers, or services can access KVM. If immediate patching is not possible, reduce exposure by restricting access to /dev/kvm, disabling nested virtualization where feasible, limiting local shell access on virtualization hosts, and moving untrusted workloads away from affected hosts until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor backport or upstream fix for the KVM arm64 nested_mmus reallocation under mmu_lock. Validate using the distribution package changelog, kernel advisory metadata, or source-level confirmation that the relevant KVM arm64 patch is present. Inventory arm64 systems with KVM enabled and verify that the running kernel, not only the installed package, is updated after reboot. Check access controls on /dev/kvm to ensure only trusted users and services can use hardware virtualization. Where appropriate, run vendor regression tests or KVM selftests for arm64 nested virtualization after patching to confirm expected behavior.

Typical attack path

1. Obtain local code execution on an affected arm64 Linux system with access to KVM functionality, such as permission to use /dev/kvm.
2. Create or manipulate a KVM virtual machine using nested virtualization-related behavior.
3. Trigger nested MMU initialization or resizing while inducing MMU notifier activity that causes nested MMU state to be walked concurrently.
4. Win the race so that the kernel walks the old nested_mmus array after it has been freed.
5. Leverage the resulting use-after-free for denial of service through kernel panic or, with additional exploitation work, kernel memory corruption and privilege escalation.

How to detect it

There is no known universal network indicator for this vulnerability because exploitation is local and occurs inside the kernel. To assess possible prior exploitation, review host kernel logs from journalctl, dmesg, persistent syslog, crash dumps, hypervisor monitoring, and EDR telemetry for kernel oops, panic, KASAN, BUG, general protection fault, or slab use-after-free messages involving KVM arm64 nested MMU code. Pay particular attention to crashes occurring shortly after VM creation, nested virtualization activity, memory unmapping, or repeated interactions with /dev/kvm. Investigate local users or processes that unexpectedly opened /dev/kvm, launched QEMU/KVM workloads, or repeatedly caused VM failures before a host crash. On systems with kernel crash dumping enabled, preserve vmcore files and inspect stack traces for kvm_vcpu_init_nested, kvm_unmap_gfn_range, kvm_nested_s2_unmap, or nested_mmus references. Absence of these artifacts does not prove non-exploitation because successful privilege escalation may leave minimal logs.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• slab-use-after-free
• kvm_vcpu_init_nested
• kvm_unmap_gfn_range
• kvm_nested_s2_unmap
• nested_mmus
• /dev/kvm
• qemu-system-aarch64
• Kernel panic - not syncing
• Oops:
• BUG: kernel NULL pointer dereference

What your security team should do

• Inventory arm64 Linux systems running KVM and identify those allowing local users, build jobs, containers, or tenants to access /dev/kvm.
• Apply vendor kernel updates that include the fix, prioritizing multi-tenant virtualization hosts and systems running untrusted workloads.
• Reboot affected systems after kernel update and verify the active running kernel is the patched version.
• Temporarily restrict /dev/kvm access to trusted administrative users and service accounts until remediation is complete.
• Disable nested virtualization on affected hosts where it is not required.
• Review recent kernel logs for KASAN, kernel oops, panic, or KVM arm64 traces involving nested MMU functions.
• Because this is not currently KEV-listed and has low EPSS, handle through expedited patch management for virtualization infrastructure rather than emergency internet-edge response, unless local untrusted KVM access exists.