Cloudanix VulnDB

CVE-2026-98871

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in error handling inside the Linux kernel can cause certain secure AMD systems to freeze when starting protected virtual machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw causes a deadlock when SEV platform initialization fails after the first RMPUPDATE operation because rmp_mark_pages_firmware is called without the lock flag while the caller already holds sev_cmd_mutex, and the subsequent reclaim path invokes sev_do_cmd.

Why it matters to the business

Systems using AMD SEV may experience kernel hangs or unavailability during secure VM initialization or recovery, potentially disrupting encrypted workloads and requiring reboots.

How an attack unfolds

An attacker with local access triggers repeated SEV initialization attempts that fail after the first page update, causing the cleanup path to contend on the already-held mutex and deadlock the crypto command handler.

How to fix it

Apply the upstream kernel patch that passes locked=true to rmp_mark_pages_firmware in the init_ex_path failure handler; rebuild and deploy the fixed kernel on all affected AMD SEV systems.

How to confirm the fix worked

Confirm the patched kernel source contains the locked=true argument, boot the new kernel, and exercise SEV initialization error paths while monitoring for mutex contention or hangs.

Typical attack path

  1. Obtain local execution on an AMD SEV-enabled host
  2. Trigger SEV platform init that succeeds on the first page but fails on a subsequent RMPUPDATE
  3. Force the error cleanup path to call reclaim while sev_cmd_mutex is held
  4. Observe deadlock in sev_do_cmd

How to detect it

Review kernel logs for repeated sev_do_cmd calls or mutex-related stalls during SEV platform initialization; correlate with dmesg entries mentioning rmp_mark_pages_firmware or init_ex_path failures.

  • __sev_platform_init_handle_init_ex_path
  • rmp_mark_pages_firmware
  • sev_cmd_mutex
  • sev_do_cmd

What your security team should do

  • Prioritize kernel updates on all AMD SEV hosts within the next maintenance window
  • Add SEV initialization logs to monitoring to detect repeated failures
  • Test error-path behavior in staging environments before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix possible deadlock in SEV init failure path __sev_platform_init_handle_init_ex_path() calls rmp_mark_pages_firmware() with locked=false while the parent function of init_ex_path already acquired the sev_cmd_mutex. In the case of an RMPUPDATE failure for any page after the first, the cleanup path would invoke reclaim pages which would result in a deadlock in sev_do_cmd. Pass locked=true to honor the lock status of the parent function.

Affected packages

Ecosystem Package Introduced Fixed