CVE-2026-93097 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
cxl/mbox: Break poison list loop on an empty payload
A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing "Protect against an uncleared _FLAG_MORE" guard was intended to bound a misbehaving device but does not cover the count == 0 case.
Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's CXL mailbox subsystem contains a logic flaw in its handling of error reporting from connected devices, specifically within the mechanism used to process lists of reported errors such as memory poisoning events. The vulnerability arises when a device returns a payload with an empty record count while simultaneously setting the CXL_POISON_FLAG_MORE flag. This specific combination indicates that there are more records available but provides no actual data in the current batch. Under normal operational parameters, the kernel driver expects to advance its internal counter of processed errors based on the number of records returned. However, when the count is zero, this advancement does not occur, leaving the state unchanged for subsequent iterations of the processing loop.
This behavior creates an infinite do-while loop because the condition checking whether more data remains relies solely on the presence of the MORE flag rather than verifying that progress has been made in consuming records. Since the counter nr_records never increments, the safeguard designed to limit the maximum number of errors processed per operation fails to trigger. Consequently, the kernel thread responsible for scanning and processing these poison lists becomes permanently blocked within this loop. This state effectively hangs the sysfs-triggered scan thread, which is critical for maintaining visibility into device health and error states.
The operational impact of this vulnerability extends beyond a simple performance degradation or temporary hang. Because the loop holds the poison.mutex lock throughout its execution, all subsequent operations requiring access to this mutex are blocked indefinitely. This includes not only further scans but also any other administrative actions that depend on updating or querying the device's error state. A malfunctioning hardware component can thus cause a denial of service by exhausting system resources and blocking critical management interfaces. Furthermore, if an attacker has physical access to the CXL bus or can manipulate firmware behavior, this flaw could be exploited intentionally to wedge the host system’s ability to manage memory errors, potentially masking malicious activity or causing sustained instability in server environments where such devices are common.
From a classification perspective, this issue aligns with CWE-835, which describes loops that do not terminate due to logic errors preventing progress variables from updating. It also relates to CWE-400 regarding uncontrolled resource consumption, as the infinite loop consumes CPU cycles and blocks mutex locks indefinitely. In terms of the MITRE ATT&CK framework for enterprise security, this vulnerability facilitates Denial of Service (T1499) by rendering system management interfaces unavailable. Additionally, it touches upon Improper Input Validation (CWE-20) because the driver fails to validate that a non-empty payload accompanies the indication of more data being available.
Mitigation strategies should focus on both immediate patching and long-term defensive coding practices. The primary remediation is applying the kernel update that resolves this specific logic error by ensuring the loop breaks when an empty payload is received, regardless of the MORE flag status. This restores proper termination conditions for the processing routine. Beyond software patches, system administrators should monitor device firmware versions and ensure they are up to date, as hardware vendors may release microcode updates that prevent devices from returning such malformed responses. Implementing strict input validation in driver code to verify both the presence of data records and the correctness of flags before entering resource-intensive loops is essential for preventing similar issues in other subsystems. Regular auditing of kernel modules against CWE standards can help identify analogous logic flaws before they are deployed into production environments, thereby enhancing overall system resilience against hardware-induced software failures.