CVE-2026-53359 Januscape for MOSK compute nodes by aandreev-mirantis · Pull Request #22 · Mirantis/security

aandreev-mirantis · 2026-07-09T17:02:53Z

Summary

Add Mirantis security advisory 0020 for CVE-2026-53359 (Januscape) affecting MOSK compute nodes
Scope all default MOSK compute nodes as high-priority: nested KVM (nested=1) on virt-capable CPUs exposes every tenant VM to the guest-to-host attack path — host-model does not mitigate
Replace exposure model with prerequisite-based scoping (unpatched kernel + nested=1 + VMX/SVM + guest root)
Document two workarounds: host nested=0 + reboot, or Nova cpu_model_extra_flags + instance restart
Address PR review: fix x86-64 typo; remove misleading host-model/host-passthrough and libvirt domain XML exposure checks

Test plan

Advisory follows repository template structure
Exposure model aligns with lab-confirmed nested=1 behavior on Ubuntu 24.04 / libvirt 10.0 / AMD
Reviewer sign-off on prerequisite exposure model and Nova cpu_model_extra_flags workaround wording

pshchelo · 2026-07-09T17:24:14Z

+
+### Overview
+
+On July 6, 2026, a high-severity vulnerability in the Linux kernel KVM/x86 hypervisor, dubbed **"Januscape" (CVE-2026-53359)**, was publicly disclosed. The flaw is a use-after-free in the KVM shadow MMU (`kvm_mmu_get_child_sp()` role-reuse logic) that has been present in the kernel since approximately 2010. It affects both Intel (VMX/EPT) and AMD (SVM/NPT) x8664 hosts and can be triggered from a guest virtual machine to corrupt host shadow page state, enabling **guest-to-host escape** (root code execution on the hypervisor) or **host kernel panic (denial of service)**.


x8664 - typo, x86-64

pshchelo · 2026-07-09T17:24:55Z

+
+**A public Proof-of-Concept (PoC) exploit that triggers host kernel panic is available**; do not run it on production hypervisors. A full guest-to-host escape exploit has not been published. The permanent fix requires a patched host kernel containing upstream fixes for both CVE-2026-53359 and CVE-2026-46113. As of July 9, 2026, Canonical has not yet shipped fixed kernels for any supported Ubuntu release used by MOSK ([Ubuntu CVE tracker](https://ubuntu.com/security/CVE-2026-53359) lists both 22.04 Jammy and 24.04 Noble as **Vulnerable**).
+
+All MOSK compute nodes are x8664 and run QEMU/KVM via libvirt. MOSK enables nested virtualization (`nested=1`) by default on compute nodes by creating `/etc/modprobe.d/qemu-system-x86.conf`. Every compute node therefore runs a vulnerable host kernel until patched.


pshchelo · 2026-07-09T17:26:20Z

CVE-2026-46113

+
+All MOSK compute nodes are x8664 and run QEMU/KVM via libvirt. MOSK enables nested virtualization (`nested=1`) by default on compute nodes by creating `/etc/modprobe.d/qemu-system-x86.conf`. Every compute node therefore runs a vulnerable host kernel until patched.
+
+**Host vs. guest exposure:** the host kernel is vulnerable on all compute nodes. The known guest-to-host attack, however, can only be launched from tenant VMs that receive virtualization CPU extensions (`vmx`/`svm`) and `/dev/kvm` inside the guest. MOSK's default Nova `vcpu_type` is `host-model`, which does not expose these flags. Deployments using `host-passthrough` (or explicit CPU flags for nested-virtualization workloads) are the primary guest-side attack launch points. Mirantis recommends assessing exposure and applying mitigations without delay.


I am not sure that host-model is safe when nested kvm is enabled.

I'd treat host-model as no protection. The real controls would be:

Patch the host kernel (commit 81ccda30b4e8 + the CVE-2026-46113 fix)

If you can't patch, set kvm_intel.nested=0 / kvm_amd.nested=0 at the module level

Explicitly mask the flag per-guest ().

I am actually pretty sure now that just setting host-model CPU when a) your host cpu does expose virtualization features (vmx/svm) and b) nested kvm is enabled will still effectively result in the guest VM having access to nested kvm

osgmirantis · 2026-07-10T15:47:45Z

CVE-2026-53359

Summary:
A malicious guest VM with root inside the guest and nested virtualization exposed by the host can corrupt host-kernel memory through a use-after-free in KVM's legacy shadow MMU. The public exploit reliably panics the host (denial of service that takes down every co-located tenant). A separate, unreleased exploit reportedly achieves full code execution as root on the host.
On current CPUs, guest memory normally uses hardware paging (EPT on Intel, NPT on AMD) and the vulnerable shadow MMU is never exercised. Exposing nested virtualization forces KVM back through the legacy shadow MMU, which is where the bug lives. A host can look fully modern and still be in scope.

Bottom line: The automated risk signals (KEV, EPSS) both read "low" and are misleading here. Treat this as a high-priority patch for any multi-tenant KVM/x86 host that exposes nested virtualization.

KEV status: Not listed in the CISA Known Exploited Vulnerabilities catalog (as of this writing).
EPSS: ≈0.18%; very low, and effectively meaningless for prioritization in this case.
CVSS: NVD had not scored it at publication. Third parties assign 7.8 (High), vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Mitigations

Patch affected KVM hosts to a fixed kernel (or apply a rebootless/live patch). This is the real fix.
Disable nested virtualization for untrusted guests as a temporary measure; it removes the attack path:
Intel: kvm_intel.nested=0
AMD: kvm_amd.nested=0
(This is a stopgap, not a substitute for patching).

Remediation:
Fixed stable kernels shipped: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260.

Restrict /dev/kvm. On systems where /dev/kvm is world-accessible, the same bug is usable as local privilege escalation to root even without a guest. Tighten permissions.
Hosts running no VMs: unload and block the KVM modules entirely.
Monitoring: treat unexplained KVM host panics as suspicious if they follow guest activity, nested-virt tests, or tenant VM churn.

CVE-2026-46333

EPSS 0.027% Accurate --> no exploit path, local-only, needs uid-0
KEV Not listedCorrect --> no in-the-wild use
Severity / CVSS None assigned
It should be remediated.

pshchelo

I think all the talk about host-model should be omitted. The reality is more complicated and nuanced than could be explained in a short announcement, but just setting guest cpu type to host-model w/o disabling nested kvm will still result in guest VM having access to nested kvm.

pshchelo · 2026-07-10T16:49:32Z

+
+All MOSK compute nodes are x8664 and run QEMU/KVM via libvirt. MOSK enables nested virtualization (`nested=1`) by default on compute nodes by creating `/etc/modprobe.d/qemu-system-x86.conf`. Every compute node therefore runs a vulnerable host kernel until patched.
+
+**Host vs. guest exposure:** the host kernel is vulnerable on all compute nodes. The known guest-to-host attack, however, can only be launched from tenant VMs that receive virtualization CPU extensions (`vmx`/`svm`) and `/dev/kvm` inside the guest. MOSK's default Nova `vcpu_type` is `host-model`, which does not expose these flags. Deployments using `host-passthrough` (or explicit CPU flags for nested-virtualization workloads) are the primary guest-side attack launch points. Mirantis recommends assessing exposure and applying mitigations without delay.


I am actually pretty sure now that just setting host-model CPU when a) your host cpu does expose virtualization features (vmx/svm) and b) nested kvm is enabled will still effectively result in the guest VM having access to nested kvm

Align scoping with lab-confirmed behavior: nested KVM enabled on virt-capable hosts exposes all tenant VMs regardless of Nova CPU settings. Add prerequisite exposure model, Nova cpu_model_extra_flags workaround, and simplified workarounds. Co-authored-by: Cursor <cursoragent@cursor.com>

Adding CVE-2026-53359 Januscape advisory

fac320c

aandreev-mirantis requested a review from osgmirantis July 9, 2026 17:06

pshchelo reviewed Jul 9, 2026

View reviewed changes

osgmirantis approved these changes Jul 10, 2026

View reviewed changes

pshchelo reviewed Jul 10, 2026

View reviewed changes

pshchelo approved these changes Jul 13, 2026

View reviewed changes

antonma14 merged commit 11e01ab into main Jul 13, 2026
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

CVE-2026-53359 Januscape for MOSK compute nodes#22

CVE-2026-53359 Januscape for MOSK compute nodes#22
antonma14 merged 2 commits into
mainfrom
0020-januscape

aandreev-mirantis commented Jul 9, 2026 •

edited

Loading

Uh oh!

pshchelo Jul 9, 2026

Uh oh!

pshchelo Jul 9, 2026

Uh oh!

pshchelo Jul 9, 2026

Uh oh!

osgmirantis Jul 10, 2026

Uh oh!

pshchelo Jul 10, 2026

Uh oh!

osgmirantis commented Jul 10, 2026

Uh oh!

pshchelo left a comment

Uh oh!

pshchelo Jul 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		### Overview

		On July 6, 2026, a high-severity vulnerability in the Linux kernel KVM/x86 hypervisor, dubbed "Januscape" (CVE-2026-53359), was publicly disclosed. The flaw is a use-after-free in the KVM shadow MMU (`kvm_mmu_get_child_sp()` role-reuse logic) that has been present in the kernel since approximately 2010. It affects both Intel (VMX/EPT) and AMD (SVM/NPT) x8664 hosts and can be triggered from a guest virtual machine to corrupt host shadow page state, enabling guest-to-host escape (root code execution on the hypervisor) or host kernel panic (denial of service).


		A public Proof-of-Concept (PoC) exploit that triggers host kernel panic is available; do not run it on production hypervisors. A full guest-to-host escape exploit has not been published. The permanent fix requires a patched host kernel containing upstream fixes for both CVE-2026-53359 and CVE-2026-46113. As of July 9, 2026, Canonical has not yet shipped fixed kernels for any supported Ubuntu release used by MOSK ([Ubuntu CVE tracker](https://ubuntu.com/security/CVE-2026-53359) lists both 22.04 Jammy and 24.04 Noble as Vulnerable).

		All MOSK compute nodes are x8664 and run QEMU/KVM via libvirt. MOSK enables nested virtualization (`nested=1`) by default on compute nodes by creating `/etc/modprobe.d/qemu-system-x86.conf`. Every compute node therefore runs a vulnerable host kernel until patched.


		All MOSK compute nodes are x8664 and run QEMU/KVM via libvirt. MOSK enables nested virtualization (`nested=1`) by default on compute nodes by creating `/etc/modprobe.d/qemu-system-x86.conf`. Every compute node therefore runs a vulnerable host kernel until patched.

		Host vs. guest exposure: the host kernel is vulnerable on all compute nodes. The known guest-to-host attack, however, can only be launched from tenant VMs that receive virtualization CPU extensions (`vmx`/`svm`) and `/dev/kvm` inside the guest. MOSK's default Nova `vcpu_type` is `host-model`, which does not expose these flags. Deployments using `host-passthrough` (or explicit CPU flags for nested-virtualization workloads) are the primary guest-side attack launch points. Mirantis recommends assessing exposure and applying mitigations without delay.

Uh oh!

Conversation

aandreev-mirantis commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

osgmirantis commented Jul 10, 2026

Uh oh!

pshchelo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aandreev-mirantis commented Jul 9, 2026 •

edited

Loading