ibmasm: fix heap over-read in ibmasm_send_i2o_message()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.86, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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 controller's 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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in ca1c857e2bb74a9fc0606128334f85316d57067b; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in b870f652877bfbe321bd0f4096fc37a93296f7b6; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in ce57fa439bd1b5d664f334a0c3e3f0e42abb0153; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in fd19eb1c75047a4ed4e855f56cafd704dc3914e0; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in fe31722b0194ff76bf8b461e8bf97a2081147787; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in c1c2417c60dbdca5ebb00462f21ee71c2d7f7083; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 9e8f6c9d4ecddda2f28baa1678340286cff3969c; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 9aad71144fa3682cca3837a06c8623016790e7ec
- Linux Linux
2.6.12
- KernelLinux
From 2.6.12 · fixed in 5.10.258; From 5.11.0 · fixed in 5.15.209; From 5.16.0 · fixed in 6.1.175; From 6.2.0 · fixed in 6.6.140; From 6.7.0 · fixed in 6.12.86; From 6.13.0 · fixed in 6.18.27; From 6.19.0 · fixed in 7.0.4
References 8
git.kernel.org
- stable/c/ca1c857e2bb74a9fc0606128334f85316d57067b
- stable/c/b870f652877bfbe321bd0f4096fc37a93296f7b6
- stable/c/ce57fa439bd1b5d664f334a0c3e3f0e42abb0153
- stable/c/fd19eb1c75047a4ed4e855f56cafd704dc3914e0
- stable/c/fe31722b0194ff76bf8b461e8bf97a2081147787
- stable/c/c1c2417c60dbdca5ebb00462f21ee71c2d7f7083
- stable/c/9e8f6c9d4ecddda2f28baa1678340286cff3969c
- stable/c/9aad71144fa3682cca3837a06c8623016790e7ec