CVE-2026-93186: cxl/mbox: Clamp mailbox output allocation to the payload size
In the Linux kernel, the following vulnerability has been resolved:
cxl/mbox: Clamp mailbox output allocation to the payload size
CXLMEMSENDCOMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxlmboxcmdctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INTMAX it WARNs and taints, and with paniconwarn=1 it panics.
The transport cxlpcimboxsendcmd() already clamps the response copy to min(out.size, payloadsize, device len), so the output buffer is never written beyond payloadsize. Clamp the allocation to payloadsize too, matching the RAW path.
Event History
Frequently Asked Questions
Who can trigger the problematic allocation?
A user able to issue the CXL_MEM_SEND_COMMAND ioctl can supply an unbounded output size. The input size is already limited to the mailbox payload size, but the affected path previously allocated based on the user-controlled output size.
What is the practical impact of a very large output size?
A large requested output size can cause a huge kvzalloc() request. Sizes above INT_MAX produce a warning and taint the kernel; systems configured with panic_on_warn=1 can panic.
Can this be used to make the mailbox transport copy more data than its payload allows?
No. The PCI mailbox transport limits response copying to the minimum of the requested output size, mailbox payload size, and device response length. The issue is the oversized allocation, not an out-of-bounds response copy.
What change resolves the issue?
The fix limits the output-buffer allocation to the mailbox payload size, matching the existing limit on the copied response and the RAW command path.