CVE-2026-53277

What it actually does

This is a race condition in the Linux kernel KVM implementation for ARM64. Certain KVM code paths that emulate address-translation behavior or perform fault-injection-related page table walks call page table walker routines without holding the expected SRCU read lock. The lock is required to protect KVM memory-slot metadata while it may be changed concurrently. If a page table walk races with memory-slot updates, the kernel may operate on stale or inconsistent virtualization memory metadata, potentially leading to host kernel crashes, KVM instability, or, in worst cases, memory corruption. Practical exploitability is currently assessed as low: EPSS is very low, the issue is not in CISA KEV, and no mature public exploitation is reported.

Why it matters to the business

Organizations running ARM64 Linux virtualization hosts with KVM could experience host instability or denial of service if this race is triggered, especially in environments that support guest memory changes, live migration, nested virtualization, or other operations that modify KVM memory slots while guests are active. A successful attack or accidental trigger could disrupt multiple virtual machines on the same host. The issue is not currently known to be exploited in the wild and is not associated with ransomware campaigns, but it should still be addressed through normal kernel maintenance because kernel virtualization bugs can have high operational blast radius.

How an attack unfolds

An attacker would generally need the ability to run code in, or otherwise influence, a VM on an affected ARM64 KVM host and cause execution paths that invoke KVM address-translation emulation or fault handling. They would then attempt to trigger those page table walks repeatedly while KVM memory-slot metadata is being changed by the virtual machine monitor or host-side management operations, such as memory hotplug, VM reconfiguration, migration-related activity, or similar lifecycle changes. Because the vulnerable code does not acquire the SRCU lock before walking the relevant tables, the attacker attempts to win a timing race so the kernel reads inconsistent or freed memory-slot state. The most likely observable outcome is a host kernel warning, oops, panic, or VM instability; reliable privilege escalation or data exposure has not been established from the available information.

How to fix it

Upgrade the Linux kernel to a version that includes the KVM ARM64 fix adding SRCU locking around the affected page table walks in __kvm_at_s12() and __kvm_find_s1_desc_level(). Use vendor-supported kernel packages from the relevant Linux distribution or platform provider, because fixed versions vary by distribution and backport stream. If immediate patching is not possible, reduce exposure by limiting untrusted workloads on ARM64 KVM hosts, disabling or restricting nested virtualization where not required, minimizing live memory reconfiguration and hotplug operations for untrusted guests, and scheduling VM lifecycle operations to reduce concurrent memory-slot churn. Where feasible, migrate sensitive or untrusted workloads away from affected ARM64 KVM hosts until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the KVM ARM64 SRCU locking issue. Validate through distribution advisories, kernel changelogs, package metadata, or source inspection showing that SRCU is acquired before the relevant calls in __kvm_at_s12() and __kvm_find_s1_desc_level(). Confirm hosts are actually running the updated kernel after reboot using uname or equivalent package inventory tooling. For exposure validation, identify ARM64 Linux systems running KVM, check whether KVM/ARM64 modules are loaded or built into the kernel, and determine whether they host untrusted or multi-tenant VMs. A successful mitigation test should show no recurring KVM ARM64 page-table-walk-related kernel warnings, oopses, or panics during VM memory lifecycle operations.

Typical attack path

1. Obtain the ability to run code inside a guest VM on an affected ARM64 KVM-based Linux host, or otherwise influence guest execution paths.
2. Generate guest activity that causes KVM to perform ARM64 address-translation emulation or fault-injection-related page table walks.
3. Create or wait for concurrent host-side KVM memory-slot changes, such as VM memory reconfiguration, hotplug, migration, or VMM-driven memory mapping updates.
4. Repeatedly trigger the vulnerable KVM paths to race the page table walk against memory-slot changes.
5. If the race is won, cause KVM to operate on stale or inconsistent memory metadata, potentially resulting in host kernel instability, VM disruption, or crash artifacts.

How to detect it

There are no reliable network indicators or simple guest-visible indicators for this issue. Detection should focus on host-level kernel telemetry from ARM64 KVM systems. Review kernel logs, journal entries, hypervisor logs, and crash dumps for warnings, oopses, panics, lockdep reports, KASAN reports, or use-after-free style messages involving KVM ARM64 page table walking, address translation emulation, nested stage-2 walking, memory-slot updates, or the affected functions. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump directories such as /var/crash, kdump/vmcore analysis, and virtualization management logs around VM memory hotplug, migration, or reconfiguration events. Because exploitation would likely manifest as timing-sensitive instability, correlate kernel crash events with concurrent VM lifecycle operations and unusual guest activity. Absence of these artifacts does not prove absence of attempted exploitation.

• walk_s1
• kvm_walk_nested_s2
• __kvm_at_s12
• __kvm_find_s1_desc_level
• KVM: arm64
• kvm->srcu
• SRCU
• BUG: kernel NULL pointer dereference
• BUG: KASAN
• use-after-free
• kernel panic
• Unable to handle kernel paging request
• Internal error: Oops
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory ARM64 Linux systems that provide KVM virtualization and prioritize those running untrusted, multi-tenant, or externally managed guest workloads.
• Apply vendor kernel updates that include the KVM ARM64 SRCU locking fix, then reboot hosts to ensure the fixed kernel is active.
• Until patched, restrict risky VM lifecycle operations for untrusted guests, including unnecessary memory hotplug, nested virtualization, and frequent memory-slot reconfiguration.
• Monitor affected virtualization hosts for kernel oops, panic, KASAN, or KVM ARM64 fault traces involving page table walks and memory-slot changes.
• Review crash dumps and host kernel logs from the period since publication for evidence of unexplained KVM host instability.
• Treat this as normal-to-moderate urgency unless the environment runs high-density ARM64 virtualization or untrusted tenant workloads, in which case patch during the next accelerated maintenance window.