CVE-2026-89731: cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read
In the Linux kernel, the following vulnerability has been resolved:
cxl/ras: Fix cxlrchgetaerinfo() out-of-bounds AER register read
cxlrchgetaerinfo() copies the RCH Downstream Port AER capability from the RCRB MMIO block using a readl() loop bounded by sizeof(struct aercapabilityregs). This struct is a software layout and its embedded struct pcietlplog is larger than the on-wire AER capability. As a result the loop reads past the mapped AER register block.
The over-read also populates the software-only tail fields including headerlog.headerlen. An out-of-range headerlen passed to pcieprinttlplog() can then loop past the header log buffer and cause a second out-of-bounds read.
The read was correct when introduced, but struct pcietlplog has since grown (Header Log and TLP Prefix Log sizes, headerlen and flit fields), so sizeof(struct aercapabilityregs) no longer matches the physical AER capability.
Bound the read to the physical AER registers, header through the 16 byte Header Log. Zero the destination first so the software-only fields are deterministic.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the kernel fix for cxl_rch_get_aer_info() to bound the MMIO readl() loop to the physical AER registers (header_log.header_len through the 16-byte Header Log) so it cannot loop past the mapped AER register block.
Linux kernel (cxl/ras) cxl_rch_get_aer_info() AER register read bounds = Bound the read to the physical AER registers, header_log through the 16 byte Header Log - Configuration
Apply the fix logic in cxl/ras so the destination is zeroed before copying/populating the software-only tail fields, preventing any over-read/OOB read from populating those tail fields.
Linux kernel (cxl/ras) Zeroing destination before copying software-only tail fields = Zero the destination first
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected code path is the CXL RAS handling for an RCH Downstream Port, where AER capability data is copied from the RCRB MMIO block. Systems that do not use this path are not described as affected by the provided information.
What happens after the initial out-of-bounds register read?
The over-read can populate software-only fields, including header_log.header_len. If that value is out of range and is passed to pcie_print_tlp_log(), processing can read past the header log buffer a second time.
What does the resolved change do to prevent the issue?
It limits MMIO reads to the physical AER registers through the 16-byte Header Log rather than using the size of the software structure. It also zeroes the destination structure first so software-only fields have deterministic values.