CVE-2026-46064

In the Linux kernel, the following vulnerability has been resolved:

ibmasm: fix heap over-read in ibmasm_send_i2o_message()

The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO.

Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure.

Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controllers free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it.

Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/9aad71144fa3682cca3837a06c8623016790e7ec
• https://git.kernel.org/stable/c/9e8f6c9d4ecddda2f28baa1678340286cff3969c
• https://git.kernel.org/stable/c/b870f652877bfbe321bd0f4096fc37a93296f7b6
• https://git.kernel.org/stable/c/c1c2417c60dbdca5ebb00462f21ee71c2d7f7083
• https://git.kernel.org/stable/c/ca1c857e2bb74a9fc0606128334f85316d57067b
• https://git.kernel.org/stable/c/ce57fa439bd1b5d664f334a0c3e3f0e42abb0153
• https://git.kernel.org/stable/c/fd19eb1c75047a4ed4e855f56cafd704dc3914e0
• https://git.kernel.org/stable/c/fe31722b0194ff76bf8b461e8bf97a2081147787