EUVD-2026-80508
GHSA-rfwm-m824-24pp
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
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).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
6DescriptionCVE.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.
AnalysisAI
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all LoongArch-based hosts running KVM, identify which of them perform live migration or dirty-page tracking, confirm the KVM/kernel package versions in use against the vendor advisory, and apply the available vendor patch to the highest-risk hosts first; where patching cannot be completed immediately, pause live migration on affected hosts and tighten access to /dev/kvm and VM file descriptors to trusted virtualization administrators only. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stal
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed f
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations fo
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM execu
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today