{"id":90,"date":"2026-07-08T09:00:00","date_gmt":"2026-07-08T09:00:00","guid":{"rendered":"https:\/\/backendside.com\/blog\/2026\/07\/08\/cve-2026-53359-januscape-kvm-vm-escape-fixes\/"},"modified":"2026-07-08T16:52:07","modified_gmt":"2026-07-08T16:52:07","slug":"cve-2026-53359-januscape-kvm-vm-escape-fixes","status":"publish","type":"post","link":"https:\/\/backendside.com\/blog\/2026\/07\/08\/cve-2026-53359-januscape-kvm-vm-escape-fixes\/","title":{"rendered":"CVE-2026-53359 (Januscape): KVM VM-Escape Flaw in the Linux Kernel \u2014 Fixes and Kernels With a Patch"},"content":{"rendered":"

A single mismatched flag deep inside how KVM tracks guest memory turned into a full virtual-machine escape. CVE-2026-53359<\/strong> — nicknamed “Januscape”<\/strong> — is a use-after-free in the Linux kernel’s x86 shadow memory-management unit (MMU) that lets code running inside a guest VM reach out and corrupt memory on the host that runs it. It affects both Intel and AMD hosts, and the vulnerable code had been sitting in the kernel, unnoticed, for roughly 16 years<\/strong>.<\/p>\n

If you run virtual machines on Linux — a hypervisor host, a cloud compute node, or a workstation running nested VMs — this is a patch-now issue. Here is a plain-English breakdown of what it is, whether you are exposed, and exactly which kernels contain the fix.<\/p>\n

The short version<\/h2>\n
    \n
  • What:<\/strong> A use-after-free in KVM’s x86 shadow MMU (arch\/x86\/kvm\/mmu\/mmu.c<\/code>).<\/li>\n
  • Impact:<\/strong> Guest-to-host VM escape — a malicious or compromised guest can corrupt host memory and potentially execute code on the host. On some distributions it can also be used for local privilege escalation.<\/li>\n
  • Who is affected:<\/strong> Intel and AMD x86 hosts running KVM where nested virtualization is available<\/strong>. The bug is triggerable from inside a guest.<\/li>\n
  • Age:<\/strong> The flawed code was introduced around August 2010 and stayed latent until June 2026 — about 16 years.<\/li>\n
  • Status:<\/strong> Patched upstream on 19 June 2026 (mainline commit 81ccda30b4e8<\/code>, released in 7.2-rc1). It was demonstrated as a zero-day during Google’s KVMCTF bug-bounty program.<\/li>\n
  • Severity:<\/strong> Rated High<\/strong> by distributions. NVD had not published a numeric CVSS score at the time of writing.<\/li>\n
  • It is two CVEs, not one:<\/strong> the complete fix also requires a companion patch for CVE-2026-46113<\/strong> in the same code. A kernel carrying only the CVE-2026-53359 commit is still exploitable — see “Januscape is actually two bugs” below.<\/li>\n<\/ul>\n

    What actually goes wrong<\/h2>\n

    To virtualize memory, KVM builds “shadow” page tables that mirror what the guest thinks its memory map looks like. Each shadow page carries a role<\/em> that records how it is being used — including whether it is a direct<\/strong> mapping (direct=1<\/code>) or an indirect one (direct=0<\/code>).<\/p>\n

    The bug is that when KVM looks up or allocates a child shadow page, it did not compare that role<\/strong> before reusing an existing page. So a guest can arrange for a page-directory entry that once described a direct leaf mapping to be reinterpreted as pointing at a non-leaf page (direct=1<\/code> vs direct=0<\/code>). The reverse-mapping (“rmap”) bookkeeping that KVM keeps for that page is now wrong.<\/p>\n

    The dangerous consequence: those stale rmap entries can survive a memslot deletion<\/strong>. Once the underlying shadow page is freed, the leftover references still point into that freed memory — a classic use-after-free. A guest that drives this deliberately can steer the freed-and-reused memory to corrupt host state, which is the foundation for a VM escape. The two-faced “same page, two contradictory roles” behaviour is what earned it the name Januscape<\/em>, after Janus, the two-faced Roman god.<\/p>\n

    Are you exposed?<\/h2>\n

    The exposure condition is straightforward: an x86 KVM host (Intel or AMD) where nested virtualization is enabled.<\/strong> A hostile guest is the attacker. If you run untrusted or multi-tenant guests, treat this as urgent.<\/p>\n

    Check your kernel version:<\/strong><\/p>\n

    uname -r<\/code><\/pre>\n
    Compare it against the fixed versions in the table below.<\/p>\n
    Check whether nested virtualization is on:<\/strong><\/p>\n
    # Intel hosts\ncat \/sys\/module\/kvm_intel\/parameters\/nested\n\n# AMD hosts\ncat \/sys\/module\/kvm_amd\/parameters\/nested<\/code><\/pre>\n
    A value of Y<\/code> or 1<\/code> means nested virtualization is enabled and the host is in the vulnerable configuration until patched.<\/p>\n
    Solution 1 — Patch the kernel (the real fix)<\/h2>\n
    Updating to a fixed kernel and rebooting is the durable remediation. On most systems that is simply:<\/p>\n
    # Debian \/ Ubuntu\nsudo apt update && sudo apt upgrade\nsudo reboot\n\n# RHEL \/ Fedora \/ Alma \/ Rocky\nsudo dnf upgrade kernel\nsudo reboot\n\n# openSUSE\nsudo zypper patch\nsudo reboot<\/code><\/pre>\n
    A reboot into the new kernel is required — a running host keeps executing the vulnerable code until it boots the patched kernel (unless you apply a live-patch, where your vendor offers one).<\/p>\n
    Kernels that contain the fix<\/h2>\n
    The fix landed in mainline and was backported to the maintained stable series. You are safe if you are running at or above<\/strong> the version listed for your series:<\/p>\n\n\n\n\n\n\n\n\n\n\n
    Kernel series<\/th>\nFirst fixed version<\/th>\n<\/tr>\n<\/thead>\n
    Mainline<\/td>\n7.2-rc1<\/strong> (commit 81ccda30b4e8<\/code>)<\/td>\n<\/tr>\n
    7.1.x<\/td>\n7.1.3<\/strong><\/td>\n<\/tr>\n
    6.18.x (LTS)<\/td>\n6.18.38<\/strong><\/td>\n<\/tr>\n
    6.12.x (LTS)<\/td>\n6.12.95<\/strong><\/td>\n<\/tr>\n
    6.6.x (LTS)<\/td>\n6.6.144<\/strong><\/td>\n<\/tr>\n
    6.1.x (LTS)<\/td>\n6.1.177<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Distribution packages<\/strong> carry their own version numbers — match against your distro’s advisory rather than the upstream number:<\/p>\n
      \n
    • Debian:<\/strong> linux<\/code> 6.12.95-1<\/strong> (trixie) and 7.1.3-1<\/strong> (sid).<\/li>\n
    • Ubuntu:<\/strong> tracked as High<\/strong> priority across all supported releases; install the latest linux-image<\/code> for your release and confirm status on Ubuntu’s CVE page. Because HWE and cloud kernels (aws, azure, gcp, oracle, raspi…) ship separately, update whichever variant your host runs.<\/li>\n
    • RHEL \/ Alma \/ Rocky \/ Fedora and Amazon Linux:<\/strong> pull the newest kernel from your vendor’s errata and reboot.<\/li>\n<\/ul>\n
      Stable-series fix numbers are the versions in which the backport first appeared; any later release in the same series also contains the fix. Always cross-check your distribution’s own security advisory for the exact package build, since backport version numbers differ from upstream.<\/p>\n
      Important: Januscape is actually two bugs — patch both<\/h2>\n
      Do not verify your remediation by CVE-2026-53359 alone. The complete upstream fix is two<\/strong> commits closing two<\/strong> CVEs in the same corner of the KVM code:<\/p>\n
        \n
      • CVE-2026-53359<\/strong> — commit 81ccda30b4e8<\/code><\/li>\n
      • CVE-2026-46113<\/strong> — commit 0cb2af2ea66a<\/code> (a closely related flaw in the same path)<\/li>\n<\/ul>\n
        A kernel that carries only the first commit is still exploitable<\/strong> through the second. Because most people check remediation by looking up a single CVE ID, it is easy to see “CVE-2026-53359 — fixed,” tick the box, and remain vulnerable. When you install a vendor or mainline kernel, confirm both<\/strong> CVEs are addressed — not just the headline one. The upstream stable releases in the table above include both fixes; for distribution kernels, check that the changelog references both CVE IDs.<\/p>\n
        Solution 2 — Interim mitigation: disable nested virtualization<\/h2>\n
        If you cannot patch and reboot immediately, and you do not<\/strong> rely on nested virtualization, disabling it removes the trigger condition and closes the attack surface. Do this only after confirming no guest depends on it — disabling it will break any VM that runs its own hypervisor inside.<\/p>\n
        Disable it persistently and reload the KVM module (or reboot):<\/p>\n
        # Intel\necho \"options kvm_intel nested=0\" | sudo tee \/etc\/modprobe.d\/kvm-no-nested.conf\n\n# AMD\necho \"options kvm_amd nested=0\" | sudo tee \/etc\/modprobe.d\/kvm-no-nested.conf\n\n# Apply (no running VMs must be using the module), then verify:\nsudo modprobe -r kvm_intel && sudo modprobe kvm_intel   # or kvm_amd\ncat \/sys\/module\/kvm_intel\/parameters\/nested                # expect: N<\/code><\/pre>\n
        On a busy hypervisor you usually cannot unload the module while guests are running, so this typically takes a reboot to take effect. Before making a fleet-wide change, check which VMs actually use nested virtualization (KVM exposes nested_run<\/code> counters per vCPU) so you do not silently break a workload that depends on it.<\/p>\n
        Solution 3 — Reduce blast radius<\/h2>\n
          \n
        • Do not run untrusted guests<\/strong> on unpatched hosts. The attacker in this scenario is the guest itself.<\/li>\n
        • Prioritize multi-tenant and shared hosts.<\/strong> Anywhere you run workloads you do not fully control, patch first.<\/li>\n
        • Live-migrate where you can.<\/strong> If your platform supports it, evacuate guests off an unpatched node, patch it, and migrate back — no guest downtime.<\/li>\n
        • Keep nested virtualization off by default<\/strong> on hosts that have no need for it, even after patching. It is a large attack surface you can simply not expose.<\/li>\n<\/ul>\n
          Timeline<\/h2>\n
            \n
          • Aug 2010:<\/strong> The flawed shadow-MMU code is introduced (commit 2032a93d66fa<\/code>).<\/li>\n
          • Jun 2026:<\/strong> Demonstrated as a working zero-day guest escape during Google’s KVMCTF.<\/li>\n
          • 19 Jun 2026:<\/strong> Fixed in mainline (commit 81ccda30b4e8<\/code>), then backported to the stable series above.<\/li>\n<\/ul>\n
            Key takeaways<\/h2>\n
              \n
            • CVE-2026-53359 \/ Januscape<\/strong> is a KVM shadow-MMU use-after-free that enables guest-to-host VM escape on Intel and AMD x86 hosts.<\/li>\n
            • You are exposed if you run an unpatched KVM host with nested virtualization enabled<\/strong> and any untrusted guests.<\/li>\n
            • Patch and reboot<\/strong> to a fixed kernel — 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3, or 7.2-rc1 and later — or the matching build from your distribution.<\/li>\n
            • Confirm both patches:<\/strong> Januscape spans two CVEs (CVE-2026-53359 and CVE-2026-46113). Verifying only the first can leave you exposed — check for both.<\/li>\n
            • If you cannot patch yet, disable nested virtualization<\/strong> as an interim mitigation, after confirming nothing depends on it.<\/li>\n
            • Treat multi-tenant and shared hypervisors as the top priority.<\/li>\n<\/ul>\n
              Check uname -r<\/code> against the table above, and if your kernel is older than the fix for its series, schedule that reboot.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Januscape (CVE-2026-53359) is a use-after-free in KVM’s x86 shadow MMU that lets a guest escape to the host on Intel and AMD systems. It sat in the kernel for ~16 years. Here is what it is, how to tell if you are exposed, the fixed kernel versions, and the interim mitigation.<\/p>\n","protected":false},"author":1,"featured_media":92,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,5],"tags":[],"class_list":["post-90","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security"],"_links":{"self":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/90","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/comments?post=90"}],"version-history":[{"count":2,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/90\/revisions"}],"predecessor-version":[{"id":97,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/90\/revisions\/97"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media\/92"}],"wp:attachment":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media?parent=90"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/categories?post=90"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/tags?post=90"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}