CVE-2026-93152

What it actually does

The nvme-apple driver performed a plain WRITE_ONCE for the queue enabled flag followed only by a wmb(), allowing the flag to become visible to other CPUs before the preceding queue initialization writes were published; concurrent interrupt and request paths performing plain reads could therefore observe an enabled queue whose state was still uninitialized.

Why it matters to the business

On Apple NVMe hardware, concurrent I/O or shutdown paths may access partially-initialized queue structures, producing kernel crashes, I/O errors, or silent data corruption that can interrupt storage operations and require reboots or data recovery.

How an attack unfolds

An attacker with local code execution on an affected Apple system triggers rapid queue creation and concurrent interrupt or request activity; the missing release/acquire ordering lets one path read the enabled flag before the queue metadata is fully visible, resulting in use of uninitialized state that can be steered toward a crash or memory corruption primitive.

How to fix it

Update to a kernel containing the referenced commit that replaces the wmb() and plain accesses with smp_store_release when enabling the queue and smp_load_acquire when testing it; apply the same helpers on the shutdown path for consistency.

How to confirm the fix worked

Confirm the presence of smp_store_release / smp_load_acquire calls around the enabled flag in apple_nvme_init_queue and related paths; exercise queue creation under interrupt load and verify absence of prior symptoms such as unexpected NVMe queue faults.

Typical attack path

1. Obtain local execution on Apple hardware running the vulnerable kernel
2. Create or reset an NVMe queue while simultaneously generating interrupts or I/O requests
3. Exploit the window where the enabled flag is visible without prior initialization writes being ordered
4. Cause the interrupt or request handler to dereference uninitialized queue fields
5. Escalate to denial of service or attempt to leverage resulting memory corruption

How to detect it

Search kernel logs for NVMe queue-related oops, warnings about uninitialized state, or repeated apple_nvme interrupt faults around queue initialization; correlate with processes that rapidly open or reset NVMe devices.

What your security team should do

• Prioritize patching Apple systems that use the nvme-apple driver
• Monitor vendor kernel updates for the memory-ordering fix and schedule rapid deployment
• Add regression tests that stress queue enable/disable under concurrent I/O