Look up another CVE · open CVE-2026-53200 in the interactive tracker
CVE-2026-53200
KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem arch/arm64. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53200 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
XN has already been extracted from its bitfield position so using FIELD_PREP() on the mask that clears XN[0] is completely broken, having the effect of unconditionally granting execute permissions... Fix the obvious mistake by manipulating the right bit.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/arm64/include/asm/kvm_nested.h
- What this is
- KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)MAINTAINERS section matched on arch/arm64/include/asm/kvm* · linux-arm-kernel@lists.infradead.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/arm64
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.19 | 7.0.13 | b95976c2ea44 |
| 6.19 | 7.1 | 49b32ddb87a3 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable KVM arm64 nested-virtualization path is reached by local KVM ioctls and guest execution through /dev/kvm, not by network packets or physical access.
- AC:LAttack complexity, low
- Once nested virtualization is available and FEAT_XNX is absent or not exposed, the faulty mask deterministically treats nested stage-2 translations as executable. The attacker controls the guest execution and the relevant nested stage-2 descriptors in the practical attack setup.
- PR:LPrivileges required, low
- The attacker needs local ability to create/run a KVM VM with nested EL2 enabled, but the traced ioctl path does not require real root or CAP_SYS_ADMIN. This is low privilege rather than high privilege.
- UI:NUser interaction, none
- No victim action is required after the attacker can run the nested VM; execution faults and shadow stage-2 mappings are handled automatically by KVM.
- S:CScope, changed
- The bug is in the host KVM enforcement of L1-controlled stage-2 execute permissions and can let an L2 guest violate the L1 hypervisor's security policy. That crosses a virtualization security boundary.
- C:HConfidentiality impact, high
- By bypassing L1-enforced execute-never/W^X policy, an attacker can plausibly gain arbitrary execution in a protected nested guest context and read data protected by that policy. There is no host memory-corruption primitive, but the crossed nested-virtualization boundary supports high confidentiality impact.
- I:HIntegrity impact, high
- The flaw directly grants execute permission where the L1 stage-2 page tables intended to deny it. This can allow attacker-controlled code execution and full integrity compromise of the protected nested guest context.
- A:HAvailability impact, high
- Arbitrary execution after bypassing the nested execute restriction can be used to crash or halt the protected guest/security domain. No host kernel panic is required for high availability impact across that boundary.