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.
A use-after-free vulnerability exists in the Linux kernel's CXL (Compute Express Link) port management code (CVE-2026-31530, CVSS 7.8). The vulnerability occurs in cxl_detach_ep() during device removal when parent ports may be accessed after being freed, leading to memory corruption or kernel crashes. This affects systems with CXL memory devices, particularly enterprise servers and data center infrastructure used in Saudi Arabia.
Immediate Actions:
1. Identify systems running Linux kernel versions 7.0-rc1 through 7.0-rc5 or affected stable versions with CXL devices
2. Check kernel logs for mutex unlock warnings or memory corruption errors related to cxl_detach_ep()
3. Disable CXL device hot-removal operations until patched
Patching Guidance:
1. Apply the official Linux kernel patch that establishes lifetime guarantees for child-parent port relationships
2. Ensure child ports hold references to parent devices until release
3. Update to patched kernel versions: 7.0 final release or later stable versions with the fix backported
4. Test patches in non-production environments first, particularly for systems with active CXL devices
Compensating Controls (if immediate patching unavailable):
1. Avoid hot-removal of CXL devices; perform removal only during scheduled maintenance windows
2. Disable CXL module reloading (cxl_acpi) in production environments
3. Implement monitoring for kernel panic events and mutex-related warnings
4. Maintain detailed logs of CXL device attachment/detachment events
Detection Rules:
1. Monitor kernel logs for: 'DEBUG_LOCKS_WARN_ON', '__mutex_unlock_slowpath', 'cxl_detach_ep'
2. Alert on kernel panic messages containing 'cxl_core' or 'cxl_port'
3. Track CXL device hot-removal events and correlate with system stability issues
4. Implement kernel module integrity monitoring for cxl_core and cxl_acpi modules
الإجراءات الفورية:
1. تحديد الأنظمة التي تعمل بإصدارات نواة Linux 7.0-rc1 إلى 7.0-rc5 أو الإصدارات المستقرة المتأثرة مع أجهزة CXL
2. فحص سجلات النواة للتحذيرات المتعلقة بفتح القفل أو أخطاء تلف الذاكرة المتعلقة بـ cxl_detach_ep()
3. تعطيل عمليات الإزالة الساخنة لأجهزة CXL حتى يتم تصحيحها
إرشادات التصحيح:
1. تطبيق رقعة نواة Linux الرسمية التي تؤسس ضمانات العمر الافتراضي لعلاقات منافذ الوالد والطفل
2. التأكد من أن منافذ الطفل تحتفظ بمراجع للأجهزة الأب حتى الإفراج عنها
3. التحديث إلى إصدارات النواة المصححة: الإصدار النهائي 7.0 أو إصدارات مستقرة أحدث مع الإصلاح المرجعي
4. اختبار الرقع في بيئات غير الإنتاج أولاً، خاصة للأنظمة التي تحتوي على أجهزة CXL نشطة
الضوابط البديلة (إذا لم يكن التصحيح الفوري متاحاً):
1. تجنب الإزالة الساخنة لأجهزة CXL؛ قم بالإزالة فقط أثناء نوافذ الصيانة المجدولة
2. تعطيل إعادة تحميل وحدة CXL (cxl_acpi) في بيئات الإنتاج
3. تنفيذ المراقبة لأحداث توقف النواة والتحذيرات المتعلقة بـ mutex
4. الاحتفاظ بسجلات مفصلة لأحداث إرفاق/فصل أجهزة CXL
قواعد الكشف:
1. مراقبة سجلات النواة للبحث عن: 'DEBUG_LOCKS_WARN_ON'، '__mutex_unlock_slowpath'، 'cxl_detach_ep'
2. التنبيه على رسائل توقف النواة التي تحتوي على 'cxl_core' أو 'cxl_port'
3. تتبع أحداث الإزالة الساخنة لأجهزة CXL والربط بمشاكل استقرار النظام
4. تنفيذ مراقبة سلامة وحدة النواة لوحدات cxl_core و cxl_acpi