CVE-2026-53200

What it actually does

This vulnerability is a Linux kernel KVM arm64 nested-virtualization permission-handling flaw. When KVM processes stage-2 page table execute-never attributes for an arm64 nested guest on systems without FEAT_XNX support, the XN[0] bit is manipulated incorrectly after it has already been extracted from its original bitfield position. The faulty bit handling can result in execute permissions being granted where execution should have been blocked. In practical terms, code running in a virtualized arm64 context may be able to execute from guest memory regions that should be non-executable, weakening memory-execution protections and potentially enabling privilege escalation within the virtualization boundary or as part of a larger exploit chain.

Why it matters to the business

Systems using affected Linux kernels for arm64 virtualization may have weakened isolation between virtualized workloads and the kernel-managed memory-permission model. The most likely business risk is increased impact from a compromised guest or local attacker: protections intended to prevent execution from certain memory pages may fail, making exploit chains more reliable. Because EPSS is currently very low and there is no known KEV listing or public exploit maturity, immediate mass exploitation is not indicated; however, kernel privilege-escalation issues in virtualization stacks should still be prioritized for infrastructure that runs untrusted or multi-tenant workloads.

How an attack unfolds

An attacker would first need code execution in a relevant arm64 virtualized context, such as within a guest or nested guest using KVM. They would then attempt to create or influence memory mappings where execution should be prohibited by the execute-never bit. Due to the incorrect XN[0] handling, KVM may translate or enforce the nested virtualization permission state incorrectly and allow execution from a page that should remain non-executable. The attacker could use this to bypass a memory-execution barrier and run injected or otherwise controlled code in a context where the kernel expected execution to be denied. On its own, this flaw is primarily a protection-bypass and privilege-escalation enabler; successful real-world compromise would likely require combining it with a separate bug that provides memory corruption, guest control, or another path to place executable payloads in restricted memory.

How to fix it

Apply a Linux kernel update that includes the upstream KVM arm64 fix for incorrect XN[0] handling in nested virtualization. If exact vendor fixed versions are not yet available, track the advisory stream for the Linux distribution or kernel provider in use and upgrade to the first kernel package that references this CVE or the KVM arm64 nested-virtualization XN[0] fix. Where patching cannot be completed immediately, reduce exposure by disabling nested virtualization for arm64 KVM workloads where it is not required, avoiding execution of untrusted guests on affected hosts, and prioritizing patch deployment on multi-tenant virtualization infrastructure.

How to confirm the fix worked

Confirm the running kernel version is newer than the vendor-fixed build or contains the relevant upstream KVM arm64 patch. Validate that all virtualization hosts have rebooted into the patched kernel, since installing kernel packages without rebooting does not remediate the running kernel. Review KVM configuration to determine whether nested virtualization is enabled and whether arm64 KVM workloads are present. Where source-based kernels are used, verify that the patch correcting XN[0] manipulation in the arm64 KVM nested-virtualization code is present. Functional validation can include checking that nested guests still operate normally after patching and that execute-never memory protections are enforced in regression tests, if such tests are available.

Typical attack path

1. Gain local code execution in an arm64 environment using KVM virtualization, especially where nested virtualization is enabled or exposed.
2. Identify a code path that causes KVM to process nested guest execute-never attributes on hardware or configurations without FEAT_XNX behavior.
3. Create or manipulate a guest memory mapping that should be non-executable.
4. Trigger the vulnerable KVM permission handling so the XN[0] state is interpreted incorrectly.
5. Execute code from a memory region that should have been blocked by execute-never permissions.
6. Use the execution-permission bypass to support a broader privilege-escalation or guest-isolation bypass chain.

How to detect it

There are no reliable, CVE-specific network indicators for this issue, and exploitation is unlikely to leave a unique log entry because the flaw is in kernel memory-permission enforcement. Detection should focus on exposure assessment and host-based anomaly review. Check kernel package inventories, running kernel versions, and KVM/nested-virtualization configuration on arm64 systems. For possible prior exploitation, review virtualization hosts for suspicious local privilege-escalation signs: unexpected guest-to-host interaction, unexplained crashes or kernel oops messages involving KVM or arm64 page-table handling, abnormal QEMU/KVM process behavior, unauthorized privileged processes, unexpected kernel module loading, and changes to host integrity baselines. Useful log sources include kernel logs, system journal, hypervisor management logs, auditd, EDR telemetry, package-management history, and virtualization orchestration logs. Because no public exploit maturity or known threat actor activity is indicated, prioritize broad behavioral hunting over IOC-only detection.

What your security team should do

• Inventory Linux arm64 systems that run KVM, prioritizing hosts that support nested virtualization or run untrusted guest workloads.
• Patch affected kernels through the relevant Linux distribution or kernel vendor and reboot hosts into the fixed kernel.
• Temporarily disable nested virtualization on arm64 KVM hosts where it is not operationally required.
• Prioritize multi-tenant, cloud, CI/CD, lab, and sandbox virtualization hosts above single-purpose trusted workloads.
• Monitor vendor advisories for exact fixed package versions because none were provided in the input data.
• Because EPSS is currently low and there is no KEV or known exploit maturity, treat this as a controlled kernel-maintenance priority unless threat intelligence changes.
• Review guest escape and local privilege-escalation detections for affected virtualization hosts, especially unexplained kernel faults, crashes, or suspicious activity from guest-controlled processes.