CVE-2023-52771

What it actually does

Race condition between delete_endpoint() and ancestor port removal in the CXL subsystem allows use-after-free when an endpoint's parent device is concurrently unregistered, resulting in kernel spinlock corruption or memory access violations during cxl_mem or cxl_port removal.

Why it matters to the business

Systems using CXL-attached memory may experience kernel panics and unexpected reboots during device hotplug or driver unload events, leading to service interruptions in servers and high-performance computing environments; low immediate risk given stable low EPSS and no KEV listing.

How an attack unfolds

An attacker with local access triggers concurrent removal of a CXL memdev and an ancestor port in an RCH topology, racing delete_endpoint() against parent unregistration; the missing device_lock on the correct parent (endpoint->dev.parent) leads to use-after-free and potential kernel memory corruption that could be leveraged for denial of service or further exploitation.

How to fix it

Apply the upstream fix in commit 37179fcc916bce8c3cc7b36d67ef814cce55142b or later stable kernel releases containing this change; rebuild and deploy updated kernels to all affected systems.

How to confirm the fix worked

Verify the presence of commit 37179fcc916bce8c3cc7b36d67ef814cce55142b in the running kernel source or confirm the patched cxl/port.c logic that acquires device_lock on endpoint->dev.parent before teardown.

Typical attack path

1. Obtain local access on a Linux system with CXL hardware or emulated topology
2. Trigger cxl_mem remove while an ancestor cxl_port is simultaneously unregistered
3. Race delete_endpoint() against parent device removal without holding the correct parent lock
4. Trigger use-after-free via spinlock on freed parent device leading to kernel panic or corruption

How to detect it

Search kernel logs and dmesg for spinlock bad magic errors, cxl_port detach_memdev workqueue activity, and call traces referencing delete_endpoint during device unbind or memdev removal events.

• BUG: spinlock bad magic on CPU
• Workqueue: cxl_port detach_memdev [cxl_core]
• delete_endpoint+0xad/0x150 [cxl_core]
• devres_release_all
• device_release_driver_internal

What your security team should do

• Prioritize patching CXL-enabled production kernels within standard maintenance windows
• Test updated kernels in staging environments that exercise CXL hotplug and driver unload paths
• Monitor kernel logs for spinlock and cxl_port detach_memdev errors on unpatched systems