Linux kernel CXL fwctl: unchecked op_size reads past the input buffer and into the device mailbox

UnscoredCVE-2026-89571Kernel, userspace & hypervisorcurated

Impact

fwctl_cmd_rpc() copies cmd->in_len bytes into a buffer sized to in_len, but the CXL callback ignored in_len and never validated the user-controlled op_size against it. cxlctl_set_feature() bounded op_size only from below, then copied op_size minus header bytes out of the buffer, so a small in_len with a large op_size reads past the allocation. Those out-of-bounds kernel bytes are placed into the CXL mailbox payload and sent to the device - a kernel memory disclosure with a convenient exfiltration channel - and a large enough op_size walks into unmapped memory and oopses the host. The Get paths likewise read the input struct without checking in_len.

Who can reach it

Local, requiring access to the CXL fwctl character device. That node is normally restricted to administrators or a device-management container, so the practical attacker is a privileged management agent or a compromised firmware-tooling process, not an ordinary tenant pod.

What to do

Patch to a stable kernel that rejects, at the single dispatch point, any request whose fixed header plus op_size does not fit in the copied-in buffer, then reboot the host. In the meantime, confirm the CXL fwctl device is not exposed into containers and that only firmware-management tooling holds it. The record lists three stable commits and no fixed version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89571 https://git.kernel.org/stable/c/14d52c15d5d99477b20a2d61fe36f347080da6cd https://git.kernel.org/stable/c/f687394af983df5660b6afae7e0d06969f3af206

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.