Cloudanix VulnDB

CVE-2026-98471

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how encrypted virtual machines are moved on the same computer could allow leftover data from one machine to remain visible after it is shut down, potentially exposing information it was supposed to protect.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability leaves stale guest memory data in CPU caches after an SEV VM is destroyed during intra-host migration because KVM skips cache maintenance on the source VM once it is converted to a non-SEV context and memory reclaim paths no longer flush caches.

Why it matters to the business

Sensitive virtual-machine memory contents may leak across VM boundaries on the same host, increasing the risk of data exposure in multi-tenant or confidential-compute environments.

How an attack unfolds

An attacker with the ability to trigger or observe intra-host SEV migrations arranges for the source VM to be torn down, then reads residual cache lines that were not flushed, obtaining data that the destination VM cannot access due to differing memory configurations.

How to fix it

Upgrade to a Linux kernel containing the cache-maintenance fix for source SEV VMs during intra-host migration; apply the change that explicitly flushes caches on the source before conversion to non-SEV.

How to confirm the fix worked

Confirm the presence of explicit cache-maintenance calls on the source VM in the KVM SEV migration code path and test intra-host SEV migrations with differing memslot configurations to verify no stale data remains.

Typical attack path

  1. Gain sufficient privileges to initiate or monitor KVM SEV intra-host migrations
  2. Trigger migration of a source SEV VM to a destination with non-identical memslots
  3. Ensure source VM destruction without cache maintenance
  4. Scan or probe CPU caches for residual guest data

How to detect it

Review KVM and hypervisor logs for SEV migration events followed by unexpected cache or memory access patterns from unrelated processes or VMs; correlate with host kernel version to identify unpatched systems.

What your security team should do

  • Prioritize kernel updates on hosts running KVM SEV workloads
  • Audit SEV migration logs for unexpected intra-host transfers
  • Disable or restrict intra-host SEV migration where operationally feasible until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed