CVE-2026-99177

What it actually does

The flaw allows concurrent removal of a page's mapping while set_page_dirty() is called on a page obtained via get_user_pages_fast() without holding the required lock, enabling a race condition in SEV guest memory population.

Why it matters to the business

Unpatched systems running KVM with SEV may experience kernel instability, crashes, or memory corruption during virtual machine memory operations, potentially disrupting hosted workloads.

How an attack unfolds

An attacker with local access triggers concurrent page mapping changes during guest memory population in a SEV-enabled KVM environment, causing the unlocked set_page_dirty() call to operate on an invalid mapping and induce undefined behavior.

How to fix it

Apply the upstream kernel patch that replaces set_page_dirty() with set_page_dirty_lock() in sev_gmem_post_populate(); update to a kernel version containing this fix for all affected distributions.

How to confirm the fix worked

Verify the presence of the corrected sev_gmem_post_populate() implementation using set_page_dirty_lock(); test SEV guest creation and memory operations under concurrent mapping stress.

Typical attack path

1. Obtain local access to a system using KVM with SEV enabled
2. Trigger guest memory population via sev_gmem_post_populate() while manipulating page mappings
3. Exploit the missing lock around set_page_dirty() to induce a race
4. Cause kernel panic, data corruption, or denial of service

How to detect it

Review kernel logs for SEV-related page dirtying errors or unexpected mapping invalidations around guest memory population; correlate with KVM SEV activity in audit or system logs.

What your security team should do

• Prioritize patching KVM/SEV hosts within the next maintenance window due to recent publication
• Monitor kernel changelogs for backports to supported distribution kernels
• Restrict untrusted local access to SEV-enabled hosts until patched