CVE-2026-31530

What it actually does

This vulnerability is a use-after-free in the Linux kernel CXL port teardown path, specifically in cxl_detach_ep() during bottom-up removal of CXL memory devices beneath a switch port. A race or cascading unregister sequence can cause parent_port to be freed while kernel code still attempts to unlock or otherwise access the associated device object. Technically, this can lead to kernel memory corruption, kernel warnings or crashes, and, in a successful exploitation scenario, potential local privilege escalation or arbitrary kernel memory manipulation. The flaw requires local access with sufficient ability to trigger relevant CXL device or module removal paths; it is not a remotely reachable network vulnerability.

Why it matters to the business

Systems using affected Linux kernels with CXL support and CXL devices may be exposed to local kernel compromise or denial of service. A successful attacker could crash affected hosts or potentially gain elevated privileges, which is especially significant on shared compute platforms, virtualization hosts, high-performance computing systems, or infrastructure using CXL memory expansion. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has very low EPSS, so broad opportunistic exploitation is unlikely; however, kernel privilege-escalation bugs should still be remediated through normal kernel update processes.

How an attack unfolds

An attacker first needs local execution on a system running an affected Linux kernel with the CXL subsystem available and relevant CXL device topology present. The attacker then attempts to trigger CXL endpoint or switch-port teardown, such as by causing device removal, driver unbind, or module reload activity that reaches cxl_detach_ep(). During concurrent or cascading detach operations, the kernel may release the parent CXL port object while another code path still assumes it is valid. If the attacker can reliably influence timing and heap reuse, the stale parent_port reference may be used after free, resulting in kernel memory corruption. In less controlled cases, exploitation is likely to manifest as a kernel warning, oops, panic, or host instability; in a more advanced scenario, it may be developed into local privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix establishing a lifetime rule where child CXL ports hold a reference to their parent device until release. Because no specific fixed package versions were provided, use the fixed kernel packages supplied by the operating system or distribution vendor and verify that the patch for cxl/port use-after-free in cxl_detach_ep() is included. Where immediate patching is not possible, reduce exposure by disabling or unloading unused CXL functionality, preventing untrusted users from performing device hotplug, driver unbind, module reload, or hardware-management operations, and restricting administrative capabilities such as CAP_SYS_ADMIN. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release containing the cxl/port parent lifetime fix. Validate by checking the installed and running kernel versions after reboot, reviewing vendor advisories or changelogs for the cxl_detach_ep() or parent_port use-after-free fix, and ensuring the host is not still booted into an older vulnerable kernel. On systems with CXL devices, perform controlled CXL device removal or module reload testing only in non-production or maintenance windows and confirm there are no kernel warnings, lock-debug messages, oopses, or panics related to cxl_detach_ep(), cxl_core, device_unregister(), or mutex unlock failures. Also verify that unnecessary CXL modules are not loaded on systems that do not require CXL support.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Confirm that the kernel includes the affected CXL port code and that CXL functionality or devices are present.
3. Trigger CXL device, endpoint, switch-port, driver unbind, or module reload paths that invoke cxl_detach_ep().
4. Race or repeat detach/removal operations so a parent CXL port object is freed while still referenced by a child or concurrent worker.
5. Cause a stale parent_port reference to be used, producing kernel memory corruption, a crash, or potentially controlled kernel execution.
6. If exploitation is reliable, use the kernel memory corruption primitive to escalate privileges or disable security controls.

How to detect it

To determine whether this may have been exploited or triggered, review kernel logs, system journal entries, crash dumps, and audit records for evidence of CXL device teardown, driver unbinds, module reloads, or kernel warnings around cxl_detach_ep(). Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore artifacts, auditd logs, sudo logs, shell history for privileged users, and EDR telemetry showing module or sysfs device-management activity. Look for lock-debug warnings, mutex unlock failures, kernel oopses, panics, or call traces referencing cxl_core, cxl_detach_ep(), devm_action_release(), devres_release_all(), device_unbind_cleanup(), really_probe(), unregister_port(), or device_unregister(). Also investigate unexpected reloads of cxl_acpi or manipulation of CXL-related sysfs paths. Because the vulnerability is a kernel memory-corruption bug, a failed attempt may leave only a crash or warning, while a successful privilege-escalation attempt may leave few direct artifacts; correlate suspicious kernel events with local login, sudo, container escape, driver management, or hardware-management activity around the same time.

• cxl_detach_ep
• cxl_core
• DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())
• WARNING: kernel/locking/mutex.c:949
• __mutex_unlock_slowpath
• mutex_unlock
• devm_action_release
• devres_release_all
• device_unbind_cleanup
• really_probe
• unregister_port
• device_unregister
• cxl_acpi
• modprobe -r cxl_acpi
• rmmod cxl_acpi
• modprobe cxl_acpi
• /sys/bus/cxl
• /sys/bus/cxl/drivers
• /sys/bus/cxl/devices
• /sys/bus/platform/drivers/cxl_acpi/unbind

What your security team should do

• Inventory Linux systems with CXL-capable kernels, loaded CXL modules, or CXL memory devices, and prioritize those for kernel updates.
• Apply vendor-provided fixed kernel packages and reboot systems so the corrected kernel is running.
• Give higher priority to multi-user systems, virtualization hosts, HPC systems, and infrastructure where local users or workloads may have ways to trigger device-management paths.
• Restrict local administrative capabilities and hardware-management access until patching is complete, especially access to driver unbind, module reload, and hotplug-related operations.
• Monitor kernel logs for CXL detach, lock-debug, mutex, use-after-free, oops, panic, or cxl_core warnings that may indicate attempted triggering or instability.
• If suspicious crashes or warnings are observed, preserve kernel logs, crash dumps, module state, command history, and audit logs before rebooting or reimaging.
• Track distribution advisories for exact fixed kernel package versions, since fixed versions vary by vendor and branch.