CVE-2026-93152 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme-apple: Use acquire/release for queue enabled state
apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state.
The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it.
Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability addressed in this update pertains to improper synchronization of shared state within the Apple NVMe driver subsystem of the Linux kernel. Specifically, the issue resides in the apple_nvme_init_queue function where the sequence of operations regarding queue initialization and the marking of the queue as enabled lacks proper memory ordering guarantees. In concurrent systems, particularly those involving hardware interrupt handling and request processing paths, ensuring that data writes are visible to other execution contexts before signaling their availability is critical for maintaining system stability and preventing undefined behavior. The original implementation relied on a write memory barrier following an atomic store operation to indicate that the queue was enabled. However this approach failed to adequately publish the preceding initialization steps to other CPU cores or interrupt handlers, creating a race condition window where downstream components might attempt to utilize uninitialized or partially initialized data structures.
From a technical perspective, the core flaw is a classic memory ordering violation often categorized under CWE-362 which describes concurrent execution using shared resources with insufficient synchronization. The problem arises because standard write barriers do not guarantee that prior writes are globally visible before subsequent stores become observable by other processors in all architectural contexts. When the enabled flag was set to true, there was no explicit release semantics ensuring that the initialization data written earlier would be committed to memory and visible to readers. Consequently, interrupt handlers or request submission paths could observe the queue as active while still accessing stale or uninitialized state information. This discrepancy can lead to kernel panics, data corruption, or unpredictable system crashes when the hardware attempts to process requests against a queue that has not been fully prepared by the driver initialization routine.
The operational impact of this vulnerability is primarily related to system reliability and potential denial of service conditions triggered during high-load scenarios or rapid device attachment events. If an interrupt occurs immediately after the enabled flag is set but before the initialization data is properly propagated across CPU caches, the kernel may attempt to process I/O requests using invalid pointers or corrupted state structures. This can result in immediate crashes requiring a system reboot or subtle data integrity issues that manifest later as filesystem errors or device malfunctions. While not directly exploitable for arbitrary code execution by an external attacker without physical access or local privileges, such instability undermines the trustworthiness of storage subsystems and can be leveraged in localized denial-of-service attacks if triggered repeatedly.
To mitigate this vulnerability, the fix implements proper acquire-release synchronization primitives instead of relying on generic memory barriers. By using a release store when marking the queue as enabled, the kernel ensures that all prior initialization writes are completed and visible to other cores before the flag change is observed. Correspondingly, acquiring loads are used in interrupt and request paths to verify the enabled state, which acts as an acquire operation ensuring that subsequent reads of the queue data see the fully initialized values. This approach aligns with modern concurrency best practices for Linux kernel development and adheres to standards defined by CWE-362 regarding proper synchronization mechanisms. Additionally maintaining consistency on the shutdown side ensures that all code paths handling the enabled state follow the same rigorous memory ordering rules, reducing the risk of similar issues arising in cleanup routines. This update reinforces the robustness of the NVMe driver against race conditions inherent in multi-core asynchronous hardware interactions.