Skip to main content

Linux Kernel KVM EUVDEUVD-2026-80508

| CVE-2026-89908 HIGH
2026-09-16 Linux GHSA-rfwm-m824-24pp
8.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Access KVM VM-fd on LoongArch host
  2. Delivery
    Trigger memslot flags-only update (dirty logging)
  3. Exploit
    Lose arch hugepage flags
  4. Execution
    Guest read fault maps misaligned PMD
  5. Persist
    Guest accesses wrong host pages
  6. Impact
    Host memory disclosure/corruption

Vulnerability Assessment

Exploitation Conditions

Requires: (1) a LoongArch host running KVM with a guest VM; (2) local access to the KVM VM-fd / VMM process (PR:L); (3) a memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE due to a GPA/HVA offset mismatch within a PMD; (4) a KVM_MR_FLAGS_ONLY memslot update - most naturally toggling KVM_MEM_LOG_DIRTY_PAGES during live migration - which zeroes the arch flags; and (5) subsequent guest read faults that then get mapped with PMD (huge) entries. These specific preconditions (alignment mismatch plus a flags-only update during migration) are the primary LIMITS on exploitation and make the vendor's AC:L optimistic; the bug does not manifest against a static, non-migrating guest with aligned memslots. Affects only the LoongArch architecture.

Impact

The vendor scores this 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), and unlike most of the sibling LoongArch cluster (which are DoS-dominant), the impact here is genuinely high: after a KVM_MR_FLAGS_ONLY memslot update (e.g. enabling KVM_MEM_LOG_DIRTY_PAGES for live migration), the arch flags are lost, a hugepage-INCAPABLE slot can be mapped with PMD entries, and the guest ends up reading/writing the WRONG host pages - a cross-boundary confidentiality AND integrity failure, not just a crash. That justifies C:H/I:H and the S:C scope change (guest→host). However, AC:L is questionable: the bug only manifests when a memslot was marked HUGEPAGE_INCAPABLE due to a specific GPA/HVA PMD-offset mismatch AND dirty-logging is toggled AND transparent/huge mappings are in play - a narrow, largely operationally-induced condition rather than a trivially reproducible one, so AC:H is more honest. No EPSS, no KEV, and no public POC are present in the input - exploitation status is 'no public exploit identified at time of analysis'. Net: a legitimately serious guest→host memory-safety bug, but real-world priority is bounded by the niche LoongArch KVM footprint and the specific migration/alignment preconditions. No SSVC data was provided.

Exploit ScenarioDerived

During a live migration of a LoongArch KVM guest, the VMM enables dirty-page logging (KVM_MR_FLAGS_ONLY) on a memslot whose GPA/HVA offsets are misaligned within a PMD. The lost arch flags cause the host to map that slot with hugepages on subsequent guest read faults, and because gfn and pfn are aligned independently, the guest silently accesses host physical pages outside its intended mapping - enabling disclosure or corruption of host/other-guest memory. No public exploit code is identified at time of analysis.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 16, 2026

On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling KVM_MEM_LOG_DIRTY_PAGES for live migration) zeroes the slot's architecture-specific flags, so a slot previously marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can subsequently be mapped with PMD-sized entries; because the mapping path aligns the guest frame number and host page frame number independently, the guest can read or write the wrong host pages, giving a local attacker with access to the KVM VM file descriptor both confidentiality and integrity impact on the host (CVSS 8.8 vendor score, AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The independent assessment rates the attack complexity higher (AC:H) because exploitation requires a misaligned memslot plus a flags-only update, typically during live migration, and does not manifest for a static guest with aligned memslots; only the LoongArch architecture is affected. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV, though the tags classify the outcome as information disclosure and the successful corruption path is a memory-safety violation with high integrity impact.

RemediationAI

Patch status is vendor-released: upgrade to Linux 6.12.110, 6.18.51 or 7.2.5 on stable branches, or to 7.3-rc2 or later on the development branch; the corresponding upstream commits are 7c6df65b53846cd7a9a1c81c6ddb42fdc08603e8, 4e4dbc341b1581dc512b85d98b768373b0398366, bc7a6849b4395f45a602db91b0fb2fb2e9ed4bba and 27a9bfee3bbcb3cabb77797354f07e0e44e49831 per https://git.kernel.org/stable/c/7c6df65b53846cd7a9a1c81c6ddb42fdc08603e8 and the accompanying references. If immediate patching is not possible on LoongArch KVM hosts, the most direct compensating control is to avoid triggering the flags-only update path: do not perform live migration with dirty-page logging (KVM_MEM_LOG_DIRTY_PAGES) on an unpatched host, since that toggle is what zeroes arch.flags - the trade-off is loss of dirty-logging-based live migration for those guests, and migration performed without dirty logging is not viable for running workloads. A second control is to eliminate the misalignment precondition by provisioning guest memory so that every memslot's GPA and HVA share the same offset within a 2 MB PMD (aligned backing and aligned huge-page reservations, avoiding mixed-offset and file-backed mappings); this prevents the slot from ever being marked KVM_MEM_HUGEPAGE_INCAPABLE and therefore prevents the unsafe huge-page mapping, but it constrains VMM memory layout and may be impossible for existing guests, and it is a configuration-level mitigation rather than a code fix. Restricting local access to the KVM VM file descriptor and the VMM process (tightening PR:L to the minimum set of trusted operators) reduces exposure because the vector requires local access (CVSS PR:L), but it does not remove the flaw. Given the high confidentiality and integrity impact and the scope change (S:C), treating affected LoongArch KVM hosts as untrusted for sensitive guest or host data until the kernel is upgraded is advisable; no public exploit code was identified at time of analysis, so emergency-only workarounds should be weighed against patch deployment speed.

Affected VersionsENISA

Linux patch: 7.3-rc2
Linux 7ab6fb505b2a7447c4a7237a12c59e3ad0c7298c <4e4dbc341b1581dc512b85d98b768373b0398366
Linux 7ab6fb505b2a7447c4a7237a12c59e3ad0c7298c <bc7a6849b4395f45a602db91b0fb2fb2e9ed4bba
Linux 7ab6fb505b2a7447c4a7237a12c59e3ad0c7298c <7c6df65b53846cd7a9a1c81c6ddb42fdc08603e8
Linux patch: 6.12.110
Linux patch: 0
Linux 7ab6fb505b2a7447c4a7237a12c59e3ad0c7298c <27a9bfee3bbcb3cabb77797354f07e0e44e49831
Linux patch: 7.2.5
Linux 6.8
Linux patch: 6.18.51

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

KVM represents each guest memory region as a memslot, and architectures maintain private state in the memslot's arch field. On LoongArch, kvm_arch_prepare_memory_region() is responsible for computing new->arch.flags - specifically whether the slot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE - but it only performs that computation for the KVM_MR_CREATE and KVM_MR_MOVE cases and returns early for all other changes. The generic memslot-management code allocates a zeroed memslot structure for each change and does not copy old->arch forward, so a KVM_MR_FLAGS_ONLY update (the class of change used, for example, when enabling or disabling dirty-page logging ahead of live migration) leaves the active slot with arch.flags == 0 - i.e. neither capable nor incapable. With both flags clear, fault_supports_huge_mapping() skips the check that the guest physical address and host virtual address share the same offset within a PMD and falls through to an alignment test on the HVA range alone. A slot that had legitimately been marked KVM_MEM_HUGEPAGE_INCAPABLE due to a GPA/HVA offset mismatch therefore becomes eligible for PMD-level (huge-page) mapping on subsequent read faults, and since kvm_map_page() aligns the gfn and the pfn independently rather than respecting a common offset, the guest ends up touching host pages that do not correspond to its own memory - the exact 'd -> f, e -> g' mis-mapping called out in the comment above the original check. The upstream fix carries the arch flags over from the old memslot for the KVM_MR_FLAGS_ONLY case, which is safe because GPA, HVA and size are guaranteed to be unchanged for that operation. No CWE was supplied in the source data; the defect class is best described as improper preservation of architecture-specific state leading to an incorrect address-translation/mapping decision.

Know when KVM gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (Linux) PRIMARY 8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 7.8 HIGH

Local VM-fd access (AV:L/PR:L); narrow alignment-mismatch-plus-migration preconditions make AC:H; guest accessing wrong host pages crosses the guest→host boundary (S:C) with full read/write corruption impact (C/I/A:H).

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
SUSE HIGH
Red Hat 5.5 MEDIUM

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Sep 16, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Sep 16, 2026 - 11:03 EUVD
CVE Published
Sep 16, 2026 - 10:32 cve.org
HIGH 8.8
CVE Published
Sep 16, 2026 - 10:32 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY

kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0.

With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check.

Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.

Executive ViewAI

Why It Matters

A memory-slot handling flaw in KVM on LoongArch hosts (CVE-2026-89908) allows an authenticated local user who can access a virtual machine's KVM file descriptor to read or write host memory outside the intended guest mapping, breaking the isolation boundary between guests and the hypervisor. Only organizations running LoongArch-based KVM virtualization hosts are exposed, and successful exploitation requires a specific memslot alignment condition that is typically encountered during live migration rather than in steady-state operation. Leadership should care because a compromise of this boundary can expose data and integrity of co-hosted workloads and the host itself, undermining the trust model for any multi-tenant or consolidated virtualization platform on that architecture.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Low
niche LoongArch KVM virtualization hosts, minimal enterprise footprint
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

More in KVM

View all
CVE-2026-27211 CRITICAL
10.0 Feb 21

Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.

CVE-2026-89930 CRITICAL
9.3 Sep 16

Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stal

CVE-2026-89918 CRITICAL
9.3 Sep 16

Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip

CVE-2026-89916 CRITICAL
9.3 Sep 16

Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed f

CVE-2026-89915 CRITICAL
9.3 Sep 16

Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations fo

CVE-2026-89914 CRITICAL
9.3 Sep 16

Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range

CVE-2026-89913 HIGH
8.8 Sep 16

A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a local

CVE-2026-89959 HIGH
8.8 Sep 16

The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access

CVE-2026-89957 HIGH
8.8 Sep 16

Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the

CVE-2026-89932 HIGH
8.8 Sep 16

Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on

CVE-2026-89929 HIGH
8.8 Sep 16

Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM execu

CVE-2026-89960 HIGH
8.8 Sep 16

A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy