EUVD-2026-103711
GHSA-hqmw-j6g2-75m9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local access to SEV-capable KVM host
-
DeliveryTrigger intra-host migration of SEV VM
-
ExploitSource VM reclaimed without cache flush
-
ExecutionObtain reclaimed physical memory pages
-
ImpactRead residual SEV guest data
Vulnerability Assessment
| Exploitation Conditions | Requires a deployment using AMD SEV (encrypted confidential VMs) under KVM AND execution of an intra-host migration, during which the source VM is converted to a non-SEV VM and its guest memory is later reclaimed (e.g., when detaching from the mmu_notifier) without cache maintenance, leaving stale data in CPU caches. Exploitation is LOCAL to the host (AV:L) and needs privileges sufficient to drive the migration/reclaim flow and to read the reclaimed memory (PR:L); no user interaction. LIMITING FACTORS: not remotely exploitable; default non-SEV KVM hosts and workloads without intra-host/live migration of SEV guests are unaffected; applies only to patched-against kernel branches running the SEV migration code path. |
| Impact | Severity drivers are mixed and point to a moderate, not urgent, priority. The CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N) confirms this is a LOCAL, authenticated-equivalent issue (PR:L) with no network exposure, so mass or remote exploitation is impossible - it requires code/operations running on the KVM host itself. EPSS is low at 0.20% (9th percentile), there is no CISA KEV listing, and no public exploit is identified, all of which argue against widespread opportunistic exploitation; the vuln.today Decision label is 'this_week' (not act_now/emergency), consistent with a real-but-contained fix-on-schedule item. The most important signal conflict is in the impact metrics: the official vector declares C:N/I:H/A:H, yet the description and the 'Information Disclosure' tag describe stale SEV guest data persisting in CPU caches - a confidentiality exposure, not an integrity/availability one. This inconsistency should be verified with the Linux CNA; treat the practical risk as disclosure of residual confidential-VM memory. Net: a legitimate confidential-computing (AMD SEV) hardening fix relevant only to a narrow class of deployments, not a high-urgency, broadly-exploitable flaw despite the 7.1 base score. |
| Exploit ScenarioDerived | On a KVM host running AMD SEV confidential VMs, an intra-host migration 'converts' the source VM to a non-SEV VM, and because KVM's reclaim path does not flush caches on teardown, residual guest data can remain in CPU caches and be recovered from reclaimed physical memory by a subsequent local context. Exploitation requires local access and the ability to drive the migration/reclaim flow on the host. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Stale AMD SEV guest data can survive in CPU caches after the source VM is destroyed during an intra-host KVM migration on Linux, allowing a local user with enough privilege to recover confidential guest memory contents from cache lines that were never scrubbed. Affected deployments are those running SEV (encrypted) guests under KVM and performing intra-host or live migration followed by memory reclaim; non-SEV hosts and environments without SEV guest migration are not exposed, and the flaw is not remotely reachable. EPSS is 0.20% (9th percentile) with no public exploit identified at time of analysis, and vendor-released fixes exist in the stable trees. Our assessed impact is confidentiality-only (C:H/I:N/A:N), while the vendor record additionally cites integrity and availability effects.
RemediationAI
Vendor-released patches are available: update to the fixed stable releases identified in the EUVD metadata (Linux 7.2.9 or 6.18.55) or to mainline 7.3-rc5, applying the corresponding git.kernel.org stable commits 37dfb676fafd1eef36fe0bb649607afbb0d5521b, d4cc2dff12116a700add601c0262132cc26e1b2c and 93de2a6a4b91b72607136dd656edf03fb399d27f for each maintained branch, and track distribution kernel advisories derived from NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-98471) and VulDB (https://vuldb.com/vuln/422142). No workaround is documented in the supplied data; the practical compensating control for hosts that cannot patch immediately is to avoid intra-host/live migration and subsequent teardown of AMD SEV guests on that host, which removes the affected convert-and-reclaim sequence but costs live-migration capability, maintenance flexibility and evacuation options. Hosts that do not run SEV guests, or that run SEV guests without intra-host migration, do not exercise the vulnerable flow, so inventorying SEV and migration usage is the fastest way to scope urgency; the vendor position is that updating the kernel is the complete fix, since the flaw is a missing cache-maintenance step in the teardown path itself rather than a configurable feature that can be switched off.
Affected VersionsENISA
Affected Packages
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
The weakness is in KVM's AMD SEV support, which keeps guest memory encrypted and relies on cache maintenance (cache flush/invalidate) when SEV-protected memory is torn down, so that decrypted or stale guest data does not persist in CPU caches. During an intra-host migration the source VM is deliberately 'converted' to a non-SEV VM, which means KVM's normal memory-reclaim paths no longer treat its pages as encrypted and therefore skip the cache maintenance that would otherwise run, for example when all guest memory is reclaimed in response to detaching from the mmu_notifier. The fix performs that cache maintenance manually on the source VM before it is destroyed. The destination VM cannot be relied upon to clean up, because KVM does not require identical guest memory configurations and the source VM may hold memory the destination never maps; enforcing equivalence would require a deep comparison of memslots and their backing memory. No CWE is assigned in the supplied data, but the failure class is a missing cache-maintenance step at teardown that leaves residual data in a shared microarchitectural resource. The precise mechanism by which a local attacker would read the residual cache contents is not described in the available sources, and the trigger depends on the SEV migration and reclaim code paths actually being exercised.
Know when the next one hits your stack
- 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
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Local host-side operation needing some privilege (AV:L/PR:L); the real impact is disclosure of residual SEV guest memory (C:H), with no integrity or availability effect.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Do cache maintenance on the source VM during intra-host migration
Manually perform cache maintenance on the source VM during intra-host migration to ensure no stale data is left in CPU caches after the VM is destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's memory reclaim flows won't trigger cache maintenance, e.g. when all guest memory is reclaimed in response to detaching from the mmu_notifier.
Note, relying on the destination VM to do cache maintenance isn't an option as KVM doesn't require identical guest memory configurations, i.e. the source VM may have access to memory that the destination VM does not. Enforcing equivalent memory configurations is infeasible, as it would require a *deep* comparison of memslots, e.g. to verify that not only are the memslot identical, but what the memslots point at is also identical.
Executive ViewAI
A high-severity vulnerability in Linux KVM (CVE-2026-98471) affects organizations using AMD SEV-encrypted virtual machines. Exploitation requires local privileged access on a host that performs intra-host migrations; if exploited, it can leak confidential guest memory, undermining trust in confidential computing. Leadership should care because this could expose sensitive data and damage customer confidence in SEV-based isolation.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB