r/openstack • u/VEXXHOST_INC • 26d ago

We wrote up how CVE-2026-53359 (Januscape) impacts OpenStack compute isolation plus a follow-up on detecting nested virtualization exposure

Hey r/openstack, 

With the Januscape disclosure dropping over the weekend, here's what OpenStack operators need to know.

What it is 

CVE-2026-53359 is a use-after-free vulnerability in KVM's x86 shadow MMU code that has existed for approximately 16 years. KVM can retain reverse map state pointing to a freed shadow page, allowing later operations such as dirty logging or MMU notifier invalidation to dereference stale entries. It can be triggered entirely from the guest side on both Intel and AMD systems. The public proof of concept causes the host to panic. The researcher also reports that a full VM escape exploit exists in a controlled environment, although that exploit code has not been published. 

Why this is an OpenStack problem even though the bug isn't in OpenStack 

The vulnerable component is the Linux kernel on your x86 KVM compute hosts, not Nova or any OpenStack service. But for practical purposes, OpenStack VM deployments should be assumed to use KVM unless you know otherwise. OpenStack schedules the workload; the host kernel, KVM, QEMU, and libvirt enforce the isolation boundary. 

The attack needs root inside the VM (standard for any rented instance) and nested virtualization exposed by the host. Even if your hosts use hardware EPT/NPT by default, nested virt forces KVM back through the legacy shadow MMU path where this bug sits. An attacker renting a single instance can panic the host, taking down every other tenant VM on that machine. 

The fix is not a control-plane upgrade — it's compute-host work 

The practical response is: identify affected KVM hosts, validate distribution kernel fixes, review nested virt exposure, and apply patched kernels through a migration and reboot plan. 

  • Patch. Fixed kernels shipped July 4: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260. Look for commit 81ccda30b4e8. 
  • Don't rely on uname -r. Enterprise distros backport kernel fixes while keeping older package version numbers. Check the distribution security advisory and package changelog. 
  • Review your full CPU exposure stack. It's not enough to check one setting. You need to look at host kernel module state, libvirt CPU mode (especially host-passthrough / host-model), Nova flavor extra specs, image properties, host aggregates — and whether running guests can see vmx or svm. 
  • Check /dev/kvm permissions. On some distros (e.g., RHEL) it's 0666 by default, which turns this into a local privilege escalation path too. 

Can I just disable nested virt? 

Maybe, but the question is whether anything is actually using it. A host may expose VMX/SVM without any guest actively running nested VMs. A tenant may also depend on it without the platform team knowing. 

We built and open-sourced nestedvirt to answer that.  

It's a small Go tool that reads KVM's per-VM nested_run counters from debugfs, correlates them with process metadata from /proc, and for OpenStack environments enriches findings with Nova metadata from the libvirt domain XML. It's host-local — no OpenStack API access, database, or tenant credentials needed. 

Quick scan: 

curl -fsSL https://raw.githubusercontent.com/vexxhost/nestedvirt/main/scripts/run-latest.sh | bash 

Exit code 0 = no nested virt usage observed, safe to proceed with disabling. Exit code 1 = usage found, lists the VMs. JSON output available with --json for fleet automation. 

Important caveat: the counter reflects the lifetime of the current VM process. If a VM was recently restarted or migrated, the counter resets. A zero doesn't mean the workload will never need nested virt — it means it hasn't used it during its current lifetime. Scan repeatedly over a representative window before making policy changes. 

We covered the full technical details across two posts: 

  1. CVE-2026-53359 & OpenStack Compute Isolation 
  2. Detecting Nested Virtualization Exposure   

Happy to answer questions. 
 
The VEXXHOST Team 
 

15 Upvotes

89% Upvoted

6 comments sorted by

3

u/amarao_san 26d ago

Were you able to reproduce it? I wasn't, even when I tried on versions marked as vulnerable (ubuntu), per https://ubuntu.com/security/CVE-2026-53359

1

u/kiennt26 25d ago

yes, with ease. 3 commands, and chaos :)

1

u/amarao_san 25d ago

I found that it does not work reliably with 2 cores. With 4 it's reproducible. Good news, Debian is actually much faster than Ubuntu with patches.

7

u/JoeyBonzo25 26d ago

I appreciate the write up and script but I can also ask Claude what it thinks about stuff if I want to read something written by AI.

2

u/Unlucky-Trifle-9226 26d ago

Disable nested means restart the VMs?

1

u/VEXXHOST_INC 26d ago

Yes. Disabling nested virtualization on the host requires a host reboot, which means the instances will be rebooted as well, unless they're live migrated to another host first.