CVE-2026-80662
nicheKernel stack info leak and iomap overread in Linux CXL RAS header log handling
The Linux kernel CXL driver defined CXL_HEADERLOG_SIZE as 512 bytes although the on-device Header Log in the RAS Capability Structure is only 64 bytes, so header_log_copy() reads 128 dwords from an 88-byte iomap mapping, overrunning it by 448 bytes. When a CXL uncorrectable AER error or a CPER protocol-error record is processed, the cxl_aer_uncorrectable_error trace event memcpy()s 512 bytes from a 64-byte stack-local source, copying 448 bytes of adjacent kernel stack memory into the trace ring buffer, which userspace can read via tracefs. A local attacker with low privileges can thereby disclose kernel stack memory (confidentiality impact), and the out-of-bounds iomap read carries an availability risk. Only systems running Linux kernels with the CXL driver's RAS/AER error handling and CXL devices that generate uncorrectable error events are affected. No exploitation is known: EPSS is 0.1% (2nd percentile), there is no public PoC, and the flaw is not in CISA KEV.
What to do: Apply the upstream kernel fix (CXL_HEADERLOG_SIZE corrected to 64 bytes, with a 128-u32 zero-padded trace buffer that preserves the existing 512-byte cxl_aer_uncorrectable_error ABI used by rasdaemon) through your distribution's kernel update channel; the advisory data does not name fixed release numbers. Restrict access to tracefs to limit the leak, and verify whether the host actually has CXL devices in use, since systems without CXL hardware cannot trigger the flaw.
| Linux kernel (cxl driver, CXL RAS/AER and CPER error handling) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512, eight times the actual on-device size. header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE (512) bytes from its source. For the CPER caller the source is struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs. Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) header_log layout in the cxl_aer_uncorrectable_error trace event. Add CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event __array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact. [ dj: Replaced 64 with SZ_64 per RichardC ]
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.