CVE-2026-45994

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

ibmasm: fix OOB reads in command_file_write due to missing size checks

The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout().

Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor.

Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.

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/0eb09f737428e482a32a2e31e5e223f2b35a71d3
• https://git.kernel.org/stable/c/44ee19422aa82a6847594866de7e5a31e4ef98b3
• https://git.kernel.org/stable/c/7b8a574da5d7ea99b943f7a3458a17a1d95e8838
• https://git.kernel.org/stable/c/a672682d39dd34e2b5ba4feb436723bed65125ff
• https://git.kernel.org/stable/c/aefc1a97da17d8309974690c8a03e439a91ebb1c
• https://git.kernel.org/stable/c/d0fb4d1dc43f8d5179917a2daaa82680993d4cdf
• https://git.kernel.org/stable/c/d50e2019c9d7c433f56d9dff65703eb904aa1fb1
• https://git.kernel.org/stable/c/ee5737891464030a189837467df3b81a273718ad