CVE-2026-98871 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's Secure Encrypted Virtualization component contains a concurrency flaw within its platform initialization sequence that can lead to a system hang or denial of service under specific failure conditions. This vulnerability resides in the sev_platform_init_handle_init_ex_path function, which is responsible for initializing SEV platforms and managing memory encryption contexts. The core issue stems from an inconsistent handling of mutex locks during error recovery paths. Specifically, when the initialization process encounters an RMPUPDATE failure after successfully processing at least one page, it triggers a cleanup routine designed to reclaim previously allocated resources.
During this cleanup phase, the code invokes rmp_mark_pages_firmware with a locked parameter set to false. However, the parent function that initiated this sequence has already acquired the sev_cmd_mutex lock to ensure exclusive access to SEV command operations. By passing locked=false, the cleanup routine attempts to perform operations that may require re-acquiring or interacting with locks in a manner inconsistent with the current locking context. This mismatch causes the system to enter a deadlock state within sev_do_cmd when it tries to execute further commands while holding the mutex but encountering blocking calls that expect an unlocked state or attempt recursive locking without proper release mechanisms.
From a technical perspective, this is classified as a classic race condition leading to deadlocking due to improper lock hierarchy management and inconsistent lock state propagation during error handling. The vulnerability aligns with CWE-833: Deadlock, which describes scenarios where two or more processes are unable to proceed because each is waiting for the other to release a resource. In this case, the resources are kernel mutexes governing access to SEV hardware commands. The failure occurs specifically in the error path rather than during normal operation, making it difficult to trigger under standard workloads but potentially exploitable by an attacker who can induce RMPUPDATE failures through crafted guest configurations or hypervisor interactions if they have sufficient privileges to influence platform initialization parameters.
The operational impact of this vulnerability is primarily a denial of service against the host system running SEV-enabled virtual machines. When the deadlock occurs, the kernel thread responsible for handling SEV commands becomes permanently blocked, preventing any subsequent SEV-related operations from completing. This can effectively disable memory encryption features for all active and future VMs on that platform until the system is rebooted or the offending module is unloaded, which may not be possible if critical services are waiting on the locked mutex. In cloud environments where multiple tenants share infrastructure, this could lead to service disruption affecting multiple virtual machines simultaneously.
Mitigation strategies involve applying kernel patches that correct the lock state propagation in the SEV initialization code path. The fix requires passing locked=true when calling rmp_mark_pages_firmware within the error handling routine of sev_platform_init_handle_init_ex_path. This ensures that the cleanup process respects the existing mutex context held by the parent function, thereby preventing the recursive locking conflict that leads to deadlock. Administrators should ensure their systems are updated with kernel versions containing this fix. Additionally, monitoring for hangs in SEV-related services and reviewing logs for RMPUPDATE failures can help identify affected instances before a full system lockup occurs.
This vulnerability highlights the importance of rigorous static analysis and formal verification of locking protocols in low-level kernel subsystems handling hardware security features. The ATT&CK framework does not directly map this specific deadlock to an attack technique as it is primarily a stability issue rather than a direct exploitation vector for privilege escalation or data exfiltration, but it falls under the broader category of availability impact techniques where attackers might attempt to induce resource exhaustion through repeated initialization failures if they can control guest parameters. Ensuring robust error handling that maintains consistent lock states across all code paths, including exceptional ones, is critical for maintaining system reliability in security-sensitive kernel components.