GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel CXL: oversized header-log size overruns the RAS iomap and leaks kernel stack via tracefs

CVE-2026-80662Kernel, userspace & hypervisorcurated

Impact

CXL_HEADERLOG_SIZE was defined eight times larger than the RAS Capability Structure's actual 64-byte header log. header_log_copy() therefore reads 128 dwords from an 88-byte MMIO mapping, running 448 bytes past the end of the iomap, and the cxl_aer_uncorrectable_error trace event memcpy()s 512 bytes from a 64-byte stack-embedded source in the CPER path. Those 448 bytes of adjacent kernel stack land in the trace ring buffer, where anyone with tracefs read access can retrieve them - useful material for defeating KASLR or lifting whatever transiently sat on that stack. This only fires on hosts with CXL devices that report RAS errors, which is an increasingly common shape for GPU nodes using CXL memory expansion, and the disclosure happens without the attacker needing to cause the error themselves.

Who can reach it

Local user with read access to tracefs (root or a monitoring/tracing group) on a host with CXL devices, once a CXL uncorrectable-error event has been recorded. The out-of-bounds MMIO read happens in kernel context on error handling, not on demand from an attacker.

What to do

Apply the fixed stable kernel from the linked commits and reboot affected CXL hosts; the fix changes a compile-time constant and the trace event staging buffers, so nothing short of a new kernel helps. As an interim measure, restrict tracefs to root and avoid handing trace-read access to tenant-facing monitoring agents on CXL-equipped nodes. No fixed release number is stated in the record beyond the stable commits.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.