CVE-2026-31530
Received Received - Intake
Use-After-Free in Linux Kernel CXL Port Handling Causes Memory Corruption

Publication date: 2026-04-22

Last updated on: 2026-04-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use after free of parent_port in cxl_detach_ep() cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing: First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this: []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0 Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the time delete_switch_port() returns, parent_port may be free, and the subsequent device_unlock(&parent_port->dev) operates on freed memory. The kernel log looks same as above, with a different offset in cxl_detach_ep(). Both of these issues stem from the absence of a lifetime guarantee between a child port and its parent port. Establish a lifetime rule for ports: child ports hold a reference to their parent device until release. Take the reference when the port is allocated and drop it when released. This ensures the parent is valid for the full lifetime of the child and eliminates the use after free window in cxl_detach_ep(). This is easily reproduced with a reload of cxl_acpi in QEMU with CXL devices present.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-28
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.21 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.11 (exc)
linux linux_kernel From 6.3 (inc) to 6.12.80 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's cxl/port component, specifically in the function cxl_detach_ep(). The issue is a use-after-free error involving the parent_port object. During the removal of CXL memory devices, the function locks ports and their parents, removes endpoints, and unregisters ports if they become empty. However, due to missing lifetime guarantees between child and parent ports, the parent_port may be accessed after it has been freed. This can happen in two scenarios: when a concurrent detach operation processes a port already freed, and when delete_switch_port() unregisters and frees the parent port but subsequent code still accesses it. The root cause is the absence of a reference holding the parent port valid for the child's lifetime, leading to potential memory corruption and kernel warnings.


How can this vulnerability impact me? :

This vulnerability can cause silent memory corruption in the Linux kernel, which may lead to instability or crashes. Specifically, accessing freed memory can cause unpredictable behavior, including kernel warnings, lock debugging errors, and potential system crashes. Such instability can affect system reliability and availability, especially in environments using CXL memory devices.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel logs for specific lock debugging warnings related to use-after-free errors in the cxl_detach_ep() function. In particular, kernel logs may show warnings such as DEBUG_LOCKS_WARN_ON and messages from __mutex_unlock_slowpath indicating unlocking of freed memory.

To detect this on your system, you can check the kernel log (e.g., using dmesg) for these warnings.

  • Run the command: dmesg | grep -i 'DEBUG_LOCKS_WARN_ON'
  • Run the command: dmesg | grep -i 'mutex_unlock'
  • Look for call traces involving cxl_detach_ep or cxl_core in the kernel logs.

Additionally, reproducing the issue can be done by reloading the cxl_acpi module in an environment with CXL devices, such as QEMU with CXL devices present.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability has been fixed. The fix establishes a lifetime rule for ports, ensuring child ports hold a reference to their parent device until release, preventing use-after-free conditions.

If updating the kernel is not immediately possible, avoid reloading or removing CXL devices or the cxl_acpi module in production environments to reduce the risk of triggering the vulnerability.

Monitor kernel logs for the described warnings to detect any exploitation attempts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart