Linux kernel maintainers published CVE-2026-46113 on May 28, 2026, describing a KVM x86 shadow paging use-after-free flaw that can leave stale reverse-map entries after an unexpected guest frame number appears in a shadow page. The bug is ugly not because it has a catchy exploit name, but because it sits in the machinery cloud operators trust to make memory virtualization boring. NVD has not yet assigned a CVSS score, which means defenders have to read the kernel prose rather than wait for a colored dashboard box. The practical answer is still straightforward: if you run x86 KVM hosts that use affected kernels, track your distribution’s fixed kernel and patch the virtualization fleet deliberately.
CVE-2026-46113 is a reminder that virtualization security often fails in the gap between what the guest is allowed to change and what the host assumes will remain coherent. The vulnerable code lives in KVM’s x86 memory-management unit, specifically in shadow paging, where KVM maintains shadow page tables to translate guest memory references into host-backed memory safely and efficiently.
The kernel record describes a stale reverse-map problem. KVM creates a shadow page for a guest mapping, later sees the guest mapping change, and then installs a new shadow page-table entry that points at a guest frame number outside the range the original shadow page was assumed to cover. When the old shadow page is eventually zapped, KVM searches the old expected range, misses the reverse-map entry that was actually installed, and leaves behind a pointer to freed memory.
That is the classic shape of a use-after-free: one part of the kernel lifecycle believes an object is gone, while another path still knows how to reach it. In user-space software that can mean a crash or code execution. In a hypervisor-adjacent kernel subsystem, it means administrators should treat the bug as a host-side correctness and isolation issue until vendors finish severity scoring and advisories.
The uncomfortable phrase in the kernel description is “literally forever.” The underlying assumption dates back to early KVM behavior, but it became more dangerous after later memory-management changes removed data structures that previously softened the impact. That distinction matters: some vulnerabilities are introduced by one bad patch, while others emerge when an old imprecision becomes unsafe under a newer design.
KVM still contains shadow MMU paths for compatibility, nested virtualization scenarios, unusual guest modes, and cases where hardware-assisted paging is unavailable, disabled, or not applicable in the way an administrator assumes. Enterprise fleets are full of exceptions: older hosts, custom kernels, special-purpose appliances, lab clusters, live-migration constraints, and nested environments created by CI systems or developer platforms.
The phrase guest frame number sounds abstract, but it is central to the bug. A GFN is KVM’s way of referring to a page-sized unit of guest physical memory. KVM’s shadow structures need to know which guest frames they represent so that updates, invalidations, dirty logging, and memory-slot changes can tear down the right mappings at the right time.
CVE-2026-46113 breaks that accounting. The shadow MMU assumes that a direct shadow page’s GFN can be derived from the shadow page’s base GFN plus the page-table-entry index. That assumption holds only if the guest mapping remains aligned with the shadow page’s original view. When guest page tables are modified between VM entries, the shadow page can contain an entry for a GFN that no longer belongs in the expected range.
That is the sort of bug that resists simple mental models. Nothing needs to “smash” memory in the crude sense. Instead, KVM makes a reasonable optimization, the guest changes the mapping at an inconvenient moment, and the cleanup path later fails to find the record it must remove.
But “narrow” is not the same as “irrelevant.” KVM is a default building block for Linux virtualization stacks, from libvirt and QEMU deployments to OpenStack, Proxmox, Kubernetes node virtualization layers, CI runners, cloud hosting platforms, and research labs. A flaw in KVM memory accounting is exactly the kind of issue that matters most to people running untrusted or semi-trusted guests.
For home users, the impact is likely to be indirect. If you use Windows in a KVM virtual machine for gaming, testing, or software compatibility, the headline may sound alarming, but exploitation would depend on the exact kernel version, KVM mode, guest behavior, and whether the vulnerable shadow paging path is in play. The more realistic concern for hobbyists is stability and host kernel correctness, not a drive-by compromise.
For cloud operators and hosting providers, the calculus is different. Multi-tenant virtualization converts rare hypervisor bugs into risk management events. Even when no exploit is public, a use-after-free in the host kernel reachable from guest-controlled memory behavior is enough to justify expedited testing and rollout once fixed packages are available.
Linux kernel CVE records also tend to be terse in a way that frustrates enterprise dashboards. They often map directly to upstream commits and stable backports, with affected versions expressed through git history and kernel release streams rather than a tidy list of branded products. That is technically precise but operationally messy.
The kernel CNA data indicates that Linux versions starting with 2.6.20 are in the affected lineage, while fixed stable releases include 6.6.140, 6.12.88, 6.18.30, 7.0.7, and the 7.1-rc3 fix line. That does not mean every system since 2.6.20 is equally exploitable in practice. It means the vulnerable logic lineage is old, and administrators should rely on distribution backports rather than naïvely comparing only upstream version strings.
This is where Linux patch management regularly punishes casual readers. A Red Hat, Ubuntu, Debian, SUSE, Arch, Fedora, or Proxmox kernel may carry a fix without matching the exact upstream kernel version named in the CVE record. Conversely, a custom kernel can remain vulnerable even if its version number looks superficially modern. For defenders, the package changelog and vendor advisory matter more than the vanity of
Here, the pattern is KVM trusting that an existing present SPTE points to the “right” shadow page. The code historically assumed that if the entry was present, it could walk into it. The new fix changes that posture: if the target GFN does not match what the shadow page should represent, KVM zaps the existing SPTE and rebuilds the state correctly.
That sounds mundane, but it is a philosophical shift from trusting internal invariants to defending them. Kernel subsystems are full of invariants because performance demands them. Hypervisors cannot revalidate everything on every memory access without paying a brutal cost. The art is knowing which assumptions are cheap enough to check and dangerous enough to mistrust.
CVE-2026-46113 lands squarely in that category. The cost of checking for a target GFN mismatch is justified because the failure mode is not merely a stale translation; it is a stale reverse-map entry that can later dereference freed memory. That is how an accounting bug becomes a memory-safety bug.
Dirty logging is central to live migration and incremental memory tracking. Hypervisors use it to determine which guest pages have changed and need to be copied or recopied. If a stale reverse-map entry survives until dirty logging walks it, KVM can dereference a freed shadow page.
MMU notifiers are similarly ordinary in Linux memory management. They let subsystems such as KVM know when host virtual memory mappings are invalidated or changed.
That is why “no CVSS yet” should not lull virtualization teams. Bugs that require specific VM memory choreography may be hard to exploit reliably, but the paths involved are real production paths. Live migration, memory pressure, memory overcommit, ballooning, and host-side invalidation behavior all live in the same neighborhood.
That distinction matters for patch responsibility. Updating the Windows guest does not fix CVE-2026-46113. The fix belongs in the host kernel. A fully patched Windows Server VM can still be sitting on an unpatched KVM host if the provider or local administrator has not updated the Linux virtualization layer.
For Windows-heavy shops that use Linux only as an invisible hypervisor substrate, this is the kind of vulnerability that can fall between teams. The Windows admins see no relevant Patch Tuesday item. The Linux admins see a KVM bug that might not be scored yet. The virtualization team sees a maintenance window problem. The attacker, if one appears, sees a boundary where ownership is blurred.
That is why mixed estates need a habit of tracking host-layer CVEs separately from guest OS patch compliance. Hypervisor bugs are not solved by endpoint management agents inside VMs. They are solved by patching the layer that owns the CPU and memory illusion.
Nested virtualization deserves special attention. Developers increasingly run hypervisors inside VMs, Windows Subsystem for Linux workflows sit near virtualization features, and CI/CD systems routinely spin up complex guest environments. Nested setups can push KVM through less-traveled MMU paths and make assumptions about paging modes more brittle.
That does not prove easy exploitation. The CVE text does not claim a known public exploit, and NVD has not yet enriched the record with attack complexity, privileges required, or impact metrics. But the affected code sits below guest privilege boundaries, and that is enough to move the issue above ordinary kernel housekeeping for operators who sell isolation as a product.
The prudent response is not panic; it is segmentation of urgency. Internet-facing desktops with no KVM use can wait for normal kernel updates. Hosts running trusted internal VMs should patch in the next planned cycle. Hosts running untrusted tenants should accelerate validation, because the value of the boundary is the business model.
This is especially important for virtualization appliances. Proxmox, enterprise Linux distributions, cloud images, and appliance-like storage or networking platforms frequently carry patched kernels that diverge from vanilla upstream numbering. Administrators should check vendor advisories, package changelogs, and kernel build metadata before declaring a system exposed or safe.
There is also a danger in assuming that only the newest kernel branches matter. The CVE record marks multiple stable lines as fixed, which is good news for conservative fleets. Operators do not necessarily need to jump to a bleeding-edge kernel; they need the correct fixed build in their chosen support branch.
The operational test is simple in principle and fussy in practice: identify every host that can run KVM guests, determine whether the running kernel contains the relevant stable backport, and reboot into the fixed kernel where required. Kernel updates that are installed but not booted do not protect running hypervisors.
For administrators, the hard part is not understanding the patch. It is deploying it without disrupting workloads. KVM host kernel updates usually require a reboot, and reboots require either live migration, guest downtime, or clustered maintenance sequencing. The very features that make virtualization flexible can also make host patching politically difficult.
Live migration can help, but only if the receiving hosts are already fixed. A rolling upgrade plan that migrates guests from vulnerable host to vulnerable host merely spreads the maintenance window without reducing exposure. The correct sequence is to drain, patch, reboot, verify, and then reintroduce capacity.
Cloud providers will make their own risk calculations, and many customers may never see the host maintenance beneath their instances. Smaller operators do not have that luxury. If your virtualization cluster is three nodes in a rack and each one carries customer VMs, the security patch is also a scheduling, capacity, and communications problem.
CVE-2026-46113 is currently best understood as a resolved kernel vulnerability with no NVD severity score and no broadly reported exploit chain. That should temper the rhetoric. It should not defer action for teams whose threat model includes malicious guests.
The kernel description is unusually rich because it lays out the failure sequence: create a shadow page from a 2MB mapping, change the PDE externally, access another page in the same region, install an SPTE with a GFN outside the original range, delete the memslot, zap the old page, then later walk a stale rmap. That is not a marketing blurb. It is a technical breadcrumb trail.
Attackers read those trails too. Even when a bug is hard to weaponize, public root-cause detail shortens the time between disclosure and serious experimentation. Defenders should assume researchers and adversaries are now studying the same sequence.
The second question is whether the affected shadow paging path is plausible in your environment. That answer may be hard to determine from the outside. Hardware-assisted paging, nested virtualization, guest modes, and KVM configuration all influence the actual path. In most production settings, it is more efficient to patch than to prove non-exposure.
The third question is whether your kernel vendor has shipped a fix. Upstream stable commits are the start of the story, not the end. Distribution security trackers and package changelogs are the authoritative operational sources for most fleets.
Finally, administrators need to verify the running kernel after maintenance. Linux systems commonly accumulate installed kernels in
The Kernel Bug Is Small, but the Assumption It Breaks Is Foundational
CVE-2026-46113 is a reminder that virtualization security often fails in the gap between what the guest is allowed to change and what the host assumes will remain coherent. The vulnerable code lives in KVM’s x86 memory-management unit, specifically in shadow paging, where KVM maintains shadow page tables to translate guest memory references into host-backed memory safely and efficiently.The kernel record describes a stale reverse-map problem. KVM creates a shadow page for a guest mapping, later sees the guest mapping change, and then installs a new shadow page-table entry that points at a guest frame number outside the range the original shadow page was assumed to cover. When the old shadow page is eventually zapped, KVM searches the old expected range, misses the reverse-map entry that was actually installed, and leaves behind a pointer to freed memory.
That is the classic shape of a use-after-free: one part of the kernel lifecycle believes an object is gone, while another path still knows how to reach it. In user-space software that can mean a crash or code execution. In a hypervisor-adjacent kernel subsystem, it means administrators should treat the bug as a host-side correctness and isolation issue until vendors finish severity scoring and advisories.
The uncomfortable phrase in the kernel description is “literally forever.” The underlying assumption dates back to early KVM behavior, but it became more dangerous after later memory-management changes removed data structures that previously softened the impact. That distinction matters: some vulnerabilities are introduced by one bad patch, while others emerge when an old imprecision becomes unsafe under a newer design.
Shadow Paging Is the Old Compatibility Path That Still Matters
Modern x86 virtualization often leans on hardware-assisted nested paging, known as EPT on Intel and NPT on AMD. That can make “shadow paging” sound like an historical footnote. It is not.KVM still contains shadow MMU paths for compatibility, nested virtualization scenarios, unusual guest modes, and cases where hardware-assisted paging is unavailable, disabled, or not applicable in the way an administrator assumes. Enterprise fleets are full of exceptions: older hosts, custom kernels, special-purpose appliances, lab clusters, live-migration constraints, and nested environments created by CI systems or developer platforms.
The phrase guest frame number sounds abstract, but it is central to the bug. A GFN is KVM’s way of referring to a page-sized unit of guest physical memory. KVM’s shadow structures need to know which guest frames they represent so that updates, invalidations, dirty logging, and memory-slot changes can tear down the right mappings at the right time.
CVE-2026-46113 breaks that accounting. The shadow MMU assumes that a direct shadow page’s GFN can be derived from the shadow page’s base GFN plus the page-table-entry index. That assumption holds only if the guest mapping remains aligned with the shadow page’s original view. When guest page tables are modified between VM entries, the shadow page can contain an entry for a GFN that no longer belongs in the expected range.
That is the sort of bug that resists simple mental models. Nothing needs to “smash” memory in the crude sense. Instead, KVM makes a reasonable optimization, the guest changes the mapping at an inconvenient moment, and the cleanup path later fails to find the record it must remove.
The Attack Surface Is Narrower Than the Word “Kernel” Suggests
The affected component is not a random desktop driver exposed to every browser tab. It is KVM on x86, and the described trigger involves shadow paging, guest page-table manipulation, memory-slot deletion, and subsequent reverse-map walks through operations such as dirty logging or MMU notifier invalidations. That narrows the practical blast radius.But “narrow” is not the same as “irrelevant.” KVM is a default building block for Linux virtualization stacks, from libvirt and QEMU deployments to OpenStack, Proxmox, Kubernetes node virtualization layers, CI runners, cloud hosting platforms, and research labs. A flaw in KVM memory accounting is exactly the kind of issue that matters most to people running untrusted or semi-trusted guests.
For home users, the impact is likely to be indirect. If you use Windows in a KVM virtual machine for gaming, testing, or software compatibility, the headline may sound alarming, but exploitation would depend on the exact kernel version, KVM mode, guest behavior, and whether the vulnerable shadow paging path is in play. The more realistic concern for hobbyists is stability and host kernel correctness, not a drive-by compromise.
For cloud operators and hosting providers, the calculus is different. Multi-tenant virtualization converts rare hypervisor bugs into risk management events. Even when no exploit is public, a use-after-free in the host kernel reachable from guest-controlled memory behavior is enough to justify expedited testing and rollout once fixed packages are available.
NVD’s Blank Score Is Not a Green Light
At publication, the NVD entry was awaiting enrichment and did not provide CVSS 4.0, CVSS 3.x, or CVSS 2.0 scoring. That is increasingly common with fast-moving kernel CVEs, and it creates a familiar problem for patch teams that depend on scanner severity to set priorities. The absence of a score is not evidence of low severity; it is evidence that the scoring pipeline has not finished.Linux kernel CVE records also tend to be terse in a way that frustrates enterprise dashboards. They often map directly to upstream commits and stable backports, with affected versions expressed through git history and kernel release streams rather than a tidy list of branded products. That is technically precise but operationally messy.
The kernel CNA data indicates that Linux versions starting with 2.6.20 are in the affected lineage, while fixed stable releases include 6.6.140, 6.12.88, 6.18.30, 7.0.7, and the 7.1-rc3 fix line. That does not mean every system since 2.6.20 is equally exploitable in practice. It means the vulnerable logic lineage is old, and administrators should rely on distribution backports rather than naïvely comparing only upstream version strings.
This is where Linux patch management regularly punishes casual readers. A Red Hat, Ubuntu, Debian, SUSE, Arch, Fedora, or Proxmox kernel may carry a fix without matching the exact upstream kernel version named in the CVE record. Conversely, a custom kernel can remain vulnerable even if its version number looks superficially modern. For defenders, the package changelog and vendor advisory matter more than the vanity of
uname -r.The Commit History Tells a More Interesting Story Than the CVE
The kernel description links this bug to a similar March 2026 fix involving MMIO SPTE handling. That earlier reference matters because it suggests maintainers were already auditing a family of assumptions around stale or mismatched shadow page-table entries. Security bugs often arrive not as isolated lightning strikes but as clusters exposed by one developer noticing a pattern.Here, the pattern is KVM trusting that an existing present SPTE points to the “right” shadow page. The code historically assumed that if the entry was present, it could walk into it. The new fix changes that posture: if the target GFN does not match what the shadow page should represent, KVM zaps the existing SPTE and rebuilds the state correctly.
That sounds mundane, but it is a philosophical shift from trusting internal invariants to defending them. Kernel subsystems are full of invariants because performance demands them. Hypervisors cannot revalidate everything on every memory access without paying a brutal cost. The art is knowing which assumptions are cheap enough to check and dangerous enough to mistrust.
CVE-2026-46113 lands squarely in that category. The cost of checking for a target GFN mismatch is justified because the failure mode is not merely a stale translation; it is a stale reverse-map entry that can later dereference freed memory. That is how an accounting bug becomes a memory-safety bug.
Dirty Logging and MADV_DONTNEED Make the Bug Operationally Plausible
The kernel record names dirty logging and MMU notifier invalidations, including those triggered byMADV_DONTNEED, as examples of operations that can walk the stale reverse map. Those are not exotic research-only mechanisms. They are part of the operational life of virtual machines.Dirty logging is central to live migration and incremental memory tracking. Hypervisors use it to determine which guest pages have changed and need to be copied or recopied. If a stale reverse-map entry survives until dirty logging walks it, KVM can dereference a freed shadow page.
MMU notifiers are similarly ordinary in Linux memory management. They let subsystems such as KVM know when host virtual memory mappings are invalidated or changed.
MADV_DONTNEED is a common memory-management hint, and while the exact exploitability of this CVE depends on many conditions, the primitives named in the record are not science fiction.That is why “no CVSS yet” should not lull virtualization teams. Bugs that require specific VM memory choreography may be hard to exploit reliably, but the paths involved are real production paths. Live migration, memory pressure, memory overcommit, ballooning, and host-side invalidation behavior all live in the same neighborhood.
WindowsForum Readers Should Care Because Windows Often Runs on KVM Too
This is a Linux kernel CVE, but the Windows angle is not incidental. Plenty of Windows workloads run as guests on KVM hosts: developer desktops using QEMU/KVM, GPU-passthrough gaming rigs, enterprise VDI experiments, lab domains, test fleets, and cloud-hosted Windows Server instances. The vulnerable code is on the Linux host, but the guest may be Windows.That distinction matters for patch responsibility. Updating the Windows guest does not fix CVE-2026-46113. The fix belongs in the host kernel. A fully patched Windows Server VM can still be sitting on an unpatched KVM host if the provider or local administrator has not updated the Linux virtualization layer.
For Windows-heavy shops that use Linux only as an invisible hypervisor substrate, this is the kind of vulnerability that can fall between teams. The Windows admins see no relevant Patch Tuesday item. The Linux admins see a KVM bug that might not be scored yet. The virtualization team sees a maintenance window problem. The attacker, if one appears, sees a boundary where ownership is blurred.
That is why mixed estates need a habit of tracking host-layer CVEs separately from guest OS patch compliance. Hypervisor bugs are not solved by endpoint management agents inside VMs. They are solved by patching the layer that owns the CPU and memory illusion.
The Real Risk Is Concentrated in Multi-Tenant and Nested Environments
The most consequential environments for CVE-2026-46113 are the ones where guests are not fully trusted. Public clouds, private clouds, university compute clusters, VPS providers, CI platforms, malware sandboxes, and customer-accessible lab environments should treat KVM memory-safety issues with more urgency than a single-user workstation.Nested virtualization deserves special attention. Developers increasingly run hypervisors inside VMs, Windows Subsystem for Linux workflows sit near virtualization features, and CI/CD systems routinely spin up complex guest environments. Nested setups can push KVM through less-traveled MMU paths and make assumptions about paging modes more brittle.
That does not prove easy exploitation. The CVE text does not claim a known public exploit, and NVD has not yet enriched the record with attack complexity, privileges required, or impact metrics. But the affected code sits below guest privilege boundaries, and that is enough to move the issue above ordinary kernel housekeeping for operators who sell isolation as a product.
The prudent response is not panic; it is segmentation of urgency. Internet-facing desktops with no KVM use can wait for normal kernel updates. Hosts running trusted internal VMs should patch in the next planned cycle. Hosts running untrusted tenants should accelerate validation, because the value of the boundary is the business model.
Kernel Version Numbers Will Mislead Anyone Who Reads Them Too Literally
The upstream record’s fixed versions are useful, but they are not the whole truth. Linux distributions backport security fixes aggressively, especially for long-term support kernels. A vendor kernel that reports an older base version may include the CVE-2026-46113 fix, while a hand-built upstream kernel may not.This is especially important for virtualization appliances. Proxmox, enterprise Linux distributions, cloud images, and appliance-like storage or networking platforms frequently carry patched kernels that diverge from vanilla upstream numbering. Administrators should check vendor advisories, package changelogs, and kernel build metadata before declaring a system exposed or safe.
There is also a danger in assuming that only the newest kernel branches matter. The CVE record marks multiple stable lines as fixed, which is good news for conservative fleets. Operators do not necessarily need to jump to a bleeding-edge kernel; they need the correct fixed build in their chosen support branch.
The operational test is simple in principle and fussy in practice: identify every host that can run KVM guests, determine whether the running kernel contains the relevant stable backport, and reboot into the fixed kernel where required. Kernel updates that are installed but not booted do not protect running hypervisors.
The Fix Is Surgical, but Deployment Is Not
The upstream fix zaps the existing SPTE when KVM detects that the target GFN does not match the shadow page it was about to reuse. That is a clean correction because it destroys the stale state before installing the new mapping. It also aligns with the broader kernel instinct to repair invariants at the boundary where they can be cheaply checked.For administrators, the hard part is not understanding the patch. It is deploying it without disrupting workloads. KVM host kernel updates usually require a reboot, and reboots require either live migration, guest downtime, or clustered maintenance sequencing. The very features that make virtualization flexible can also make host patching politically difficult.
Live migration can help, but only if the receiving hosts are already fixed. A rolling upgrade plan that migrates guests from vulnerable host to vulnerable host merely spreads the maintenance window without reducing exposure. The correct sequence is to drain, patch, reboot, verify, and then reintroduce capacity.
Cloud providers will make their own risk calculations, and many customers may never see the host maintenance beneath their instances. Smaller operators do not have that luxury. If your virtualization cluster is three nodes in a rack and each one carries customer VMs, the security patch is also a scheduling, capacity, and communications problem.
The Lack of a Public Exploit Should Not Become the Story
Security culture has developed an unhealthy dependency on exploit availability as the trigger for seriousness. That makes sense for triage at scale, but it is a poor lens for hypervisor memory bugs. By the time a reliable guest-to-host exploit appears, the defensive window has already narrowed.CVE-2026-46113 is currently best understood as a resolved kernel vulnerability with no NVD severity score and no broadly reported exploit chain. That should temper the rhetoric. It should not defer action for teams whose threat model includes malicious guests.
The kernel description is unusually rich because it lays out the failure sequence: create a shadow page from a 2MB mapping, change the PDE externally, access another page in the same region, install an SPTE with a GFN outside the original range, delete the memslot, zap the old page, then later walk a stale rmap. That is not a marketing blurb. It is a technical breadcrumb trail.
Attackers read those trails too. Even when a bug is hard to weaponize, public root-cause detail shortens the time between disclosure and serious experimentation. Defenders should assume researchers and adversaries are now studying the same sequence.
The Sensible Response Is Inventory First, Kernel Update Second
The first question is whether a system uses KVM at all. Many Linux servers do not. A web server, database host, or developer laptop with no KVM modules loaded and no virtualization workloads has a different risk profile from a hypervisor node. But inventory needs to include dormant capacity, because virtualization packages are often installed long before they are actively used.The second question is whether the affected shadow paging path is plausible in your environment. That answer may be hard to determine from the outside. Hardware-assisted paging, nested virtualization, guest modes, and KVM configuration all influence the actual path. In most production settings, it is more efficient to patch than to prove non-exposure.
The third question is whether your kernel vendor has shipped a fix. Upstream stable commits are the start of the story, not the end. Distribution security trackers and package changelogs are the authoritative operational sources for most fleets.
Finally, administrators need to verify the running kernel after maintenance. Linux systems commonly accumulate installed kernels in
/boot, and configuration management may report the fixed package as present even when the machine is still running an older vulnerable build. For hypervisors, reboot verification is not a clerical step; it is the moment the mitigation becomes real.The Lesson Hiding in the Page Tables
CVE-2026-46113 is the sort of vulnerability that rewards teams with boring asset data and punishes teams that outsource judgment to severity scores. The facts are concrete enough to act on, even while public scoring remains incomplete.- The vulnerability affects Linux KVM on x86 in shadow paging code, not Windows guests directly.
- The failure mode is a use-after-free caused by stale reverse-map state after KVM accepts a shadow page-table entry with an unexpected guest frame number.
- The record was published on May 28, 2026, and NVD enrichment had not yet produced CVSS severity metrics at the time of writing.
- Fixed upstream stable lines include 6.6.140, 6.12.88, 6.18.30, 7.0.7, and the 7.1 release-candidate fix path, but distribution backports may not match those version numbers exactly.
- Multi-tenant KVM hosts, nested virtualization platforms, CI runners, and hosting environments deserve faster attention than ordinary non-virtualization Linux systems.
- Installing a fixed kernel is not enough if the host has not rebooted into it.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:08:10-07:00
NVD - CVE-2026-46113
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:08:10-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: nist.gov
National Vulnerability Database
NIST maintains the National Vulnerability Database (NVD), a repository of information on software and hardware flaws that can compromise computer security. This is a key piece of the nation’s cybersecurity infrastructure.www.nist.gov
- Related coverage: spinics.net
stable backports for "KVM: x86: Fix shadow paging use-after-free due to unexpected GFN" — Linux Kernel
Linux Kernel: stable backports for "KVM: x86: Fix shadow paging use-after-free due to unexpected GFN"
www.spinics.net
- Related coverage: infradead.org
- Related coverage: kernel.googlesource.com
- Related coverage: labs.cloudsecurityalliance.org
