CVE-2026-93097

What it actually does

A CXL device returning count==0 with CXL_POISON_FLAG_MORE set on every iteration prevents nr_records from advancing, bypassing the max_errors guard and causing an infinite do/while loop that holds poison.mutex, wedging the sysfs scan thread and blocking all subsequent poison operations.

Why it matters to the business

Systems using affected CXL hardware can experience indefinite hangs during poison scanning, preventing device management and potentially disrupting storage or memory operations until the system is restarted.

How an attack unfolds

An attacker supplies or emulates a malfunctioning CXL device that repeatedly returns an empty payload while asserting the MORE flag; when a sysfs-triggered poison scan starts, the kernel loop never terminates, consuming the mutex and denying service to all poison-related operations on that device.

How to fix it

Apply the upstream kernel patch that adds an explicit check to break the loop when an empty payload is received; rebuild and deploy the fixed kernel image to all affected hosts.

How to confirm the fix worked

Confirm the running kernel contains the commit that stops the loop on empty payload; attempt a poison scan with a test device that returns count==0 and verify the thread completes instead of hanging.

Typical attack path

1. Attacker gains physical or virtual control of a CXL device presented to the target kernel
2. Device is configured to return count==0 and CXL_POISON_FLAG_MORE on every mbox poison-list query
3. Administrator or automated process triggers a poison scan via sysfs on the CXL device
4. Kernel enters infinite loop inside the poison-list handler while holding the mutex
5. All subsequent poison operations on the device block indefinitely

How to detect it

Look for sysfs poison-scan threads that remain in uninterruptible sleep for extended periods while accessing CXL mailbox functions; correlate with dmesg entries showing repeated poison-list queries that never complete.

What your security team should do

• Prioritize kernel updates on all systems exposing CXL devices to production workloads
• Monitor vendor advisories for backported fixes in supported distributions
• Restrict untrusted CXL devices from being attached to critical systems until patches are applied