CVE-2025-37849 Affects Arm64 KVM Hosts, Not Windows

The timing also needs correcting. Although the NVD page was modified again on July 30, 2026 and surfaced with an August 11, 2026 publication timestamp in the submitted alert, this is not a newly discovered bug or a new upstream patch. kernel.org assigned CVE-2025-37849 on May 9, 2025; upstream commit

landed for Linux 6.15, and stable fixes were released in 2025. The 2026 activity is record enrichment: kernel.org added structured affected-version data in June 2026 and a CVSS score in July.

For administrators, the immediate action is straightforward: identify Arm64 KVM hosts, especially hosts running protected KVM configurations or allowing non-root users access to

, and verify that the distribution kernel package contains the backport. Do not treat an x86_64 hypervisor merely running Windows guests under QEMU/KVM as affected by this specific flaw.

The failed-vCPU path left interrupt-controller state behind​

KVM creates a vCPU in stages. On Arm64, one of those stages initializes per-vCPU state for the virtual Generic Interrupt Controller, or vGIC. A vGIC supplies the virtual interrupt-controller behavior that Arm guests expect, including a redistributor interface associated with each virtual CPU.

The affected path then calls

to make the vCPU’s memory available to the hypervisor. In ordinary host-controlled hypervisor mappings, that function creates the needed mappings; in protected KVM configurations, it can invoke a sharing operation across the host/hypervisor boundary. Either operation can fail.

Before the fix,

returned the sharing failure to userspace, but the error path did not dismantle the vGIC state that had already been initialized. The vCPU object would later be destroyed, while vGIC structures still retained references that redistributor-device handling could traverse. That creates two outcomes named in the upstream commit message: a memory leak and a potential use-after-free.

Will Deacon’s upstream patch is deliberately small. It saves the result of

, calls

if the operation fails, and then returns the original error. The small diff should not be mistaken for a cosmetic cleanup: it puts the vGIC object’s lifetime back in step with the vCPU object’s lifetime.

Ubuntu’s kernel team independently described the affected condition as the Arm64 error path when

fails during vCPU creation. Its 2026 backport work also shows a detail easily lost in CVE summaries: older kernel branches needed an additional vGIC change,

, to provide a non-locking destruction primitive suitable for this context. In other words, the correct remediation for a long-term-support kernel may be a backported patch pair, not simply the one-line call visible in the final upstream diff.

The relevant systems are Arm64 KVM hosts, not every Linux machine​

NVD assigns CVE-2025-37849 a CVSS 3.1 score of 7.8 High, while kernel.org supplies an 8.8 High score. The vector difference is significant: NVD treats the vulnerability as local with low privileges required and unchanged scope; kernel.org’s score treats the impact as crossing a security authority boundary. Both agree that local access is required and no user interaction is needed.

Ubuntu’s security entry provides the clearest deployment-level interpretation: it classifies the bug as a local use-after-free that can be triggered by a user in the

group and says it can lead to privilege escalation. That is a meaningful condition. On most managed hypervisors,

should already be restricted to root and tightly controlled virtualization services such as libvirt or QEMU. On a shared development system where ordinary users belong to the

group, the risk profile is materially different.

The architecture condition is just as important. The defective code is in

, and the stale object is Arm’s virtual GIC vCPU state. Intel and AMD KVM hosts use the x86 KVM implementation and do not execute this Arm64 path. A Windows 11 VM, Windows Server guest, or Windows-on-Arm guest does not create exposure by itself; the question is the Linux kernel and CPU architecture of the host.

The failure also occurs during vCPU setup, not while a normally running guest is processing ordinary workloads. That limits the trigger to a vCPU-creation attempt that reaches vGIC initialization and then fails while KVM is mapping or sharing the vCPU page with the hypervisor. It does not eliminate the need to patch, but it does rule out a broad claim that every Arm64 KVM guest can exercise the bug through routine execution.

No publicly documented exploit was identified in the upstream advisory, NVD record, Ubuntu security entry, Debian tracker, or Red Hat’s public issue record. That absence is not a mitigation; it does mean administrators should describe this accurately as a fixed local memory-safety flaw with escalation potential, rather than claim a demonstrated guest-to-host escape.

The CPE is present, but it is too broad to drive patch decisions​

The submitted NVD page appears to show “CPEs loading, please wait,” which invites the reasonable question: is a CPE missing? The answer is no. NVD’s underlying record does contain CPE configuration data. It includes a generic Linux kernel CPE and a Debian 11 CPE, alongside version ranges that end at fixed stable releases.

The NVD version data marks these upstream release lines as fixed:

• Linux 6.1.135 and later in the 6.1 series.
• Linux 6.6.88 and later in the 6.6 series.
• Linux 6.12.24 and later in the 6.12 series.
• Linux 6.13.12 and later in the 6.13 series.
• Linux 6.14.3 and later in the 6.14 series.
• Linux 6.15 and later in the mainline series.

The browser-side CPE widget failing to render is therefore a presentation issue, not evidence of an untracked product. More importantly, a CPE cannot express the operational conditions that make this CVE relevant: Arm64 hardware, KVM enabled, vGIC use, the failed mapping/sharing path, and the local ability to use KVM.

That creates a real scanner problem. A CPE-only workflow can flag an x86 Linux kernel or a general-purpose Linux endpoint as affected because its package version falls inside a broad kernel range, even though the vulnerable source file is Arm64-specific. Conversely, a distribution kernel may report an older-looking version while carrying a vendor backport. The CPE is useful for inventory, but the installed vendor kernel build and the host’s Arm64 KVM configuration are the authoritative remediation checks.

Debian’s tracker demonstrates why package tracking beats raw upstream version comparison. Debian listed Linux 6.1.135-1 as fixed for Bookworm, while its Bullseye extended-support

package received the fix in

under DLA-4193-1. The package version differs from the upstream stable tag because the distribution is shipping a tested backport rather than replacing its entire kernel line.

Distribution fixes arrived on different schedules​

The upstream fix was available in Linux 6.15 and was backported to the supported stable branches listed by NVD. Distribution delivery followed each vendor’s maintenance policy rather than one shared deadline.

Debian’s May 2025 DLA-4193-1 shipped

version

for Debian 11 LTS. The Debian security tracker currently identifies Bookworm’s

package as fixed at

, while later Debian releases carry fixed kernels from newer lines.

Ubuntu lists fixed kernel packages for supported releases, including Ubuntu 24.04 LTS at

, Ubuntu 22.04 LTS at

, Ubuntu 20.04 LTS at

, and Ubuntu 18.04 LTS at

for Ubuntu Pro coverage. Canonical’s February 2026 SRU discussion records the Jammy backport being applied after compile testing and Arm64 KVM self-tests.

Red Hat’s public bug record ties the CVE to several 2026 Red Hat Enterprise Linux errata, including EUS and SAP-support streams. The public record confirms product updates exist, but it does not make a generic RHEL version string sufficient proof of remediation. Administrators should check the installed kernel package against the applicable Red Hat advisory for their exact repository and support channel.

Verify the host, not the guest image​

For Windows administrators using Linux KVM infrastructure, this should be assessed at the hypervisor layer. Start by confirming whether the host is Arm64:

An

result is the first relevant signal. Then determine whether KVM is loaded and whether local accounts have access to

. Systems that do not run KVM, systems using another architecture, and systems where untrusted users cannot access the KVM device have substantially reduced practical exposure to this CVE.

On affected hosts, inspect the full distribution kernel package version rather than relying on the abbreviated upstream-looking portion of

. For Debian and Ubuntu, use the package manager’s installed-version query; for Red Hat-derived systems, inspect the installed

,

, or vendor-specific kernel package and compare it with the relevant advisory. A custom kernel should include upstream commit

, or an equivalent backport verified by its maintainer.

One final boundary is worth keeping clear. A later May 2026 Arm64 KVM patch addressed a separate vGIC cleanup omission after

fails. That later work does not change the remediation for CVE-2025-37849, whose fix covers the subsequent

failure path. It does reinforce the operational lesson: error-path fixes in KVM must be validated by the specific patches carried in a distribution kernel, not assumed from a generic statement that a kernel “contains KVM security fixes.”

For most Windows virtualization deployments, the concrete consequence is limited: update the Arm64 Linux hypervisor kernel if it is behind its vendor’s fixed build, restrict

to trusted virtualization accounts, and close the scanner finding on x86_64 hosts only after recording that CVE-2025-37849 is confined to the Arm64 KVM implementation.