Description
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.
Published: 2026-05-27
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The ibmasm_send_i2o_message() function does not validate user-controlled fields in the dot_command_header before using the derived size for memcpy_toio(). A root user can craft an advanced command header that inflates the declared size, causing the kernel to read up to roughly 65 KB past the end of the allocated buffer. This memory is then forwarded to the service processor over MMIO, allowing information from neighboring heap objects to be exposed and potentially causing the service processor to receive an inconsistent I2O message header, leading to desynchronization or denial of service. The vulnerability is an instance of unchecked buffer over-read (CWE‑68).

Affected Systems

All Linux kernel builds that include the vulnerable ibmasm_send_i2o_message() implementation are affected. No specific patched version list is provided, but any kernel prior to the regression fix should be considered vulnerable. The issue is present at the kernel level, affecting all users with root privileges that can send custom dot commands via the IBM ASM I2O interface.

Risk and Exploitability

The exploit requires local root privileges and involves submitting a specially crafted dot command header. There is no publicly disclosed vulnerability exploitation code, the EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog. The impact is limited to the host system and can lead to information disclosure and service desynchronization of the SP. The CVSS score is not provided, but the theoretical severity is high (potentially 9+). Due to the privilege prerequisite, remote exploitation is unlikely without a prior compromise that grants root access.

Generated by OpenCVE AI on May 27, 2026 at 18:09 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply an updated Linux kernel that includes the ibmasm_send_i2o_message() fix.
  • Reboot the system so the patched kernel is active and in use.
  • If a kernel upgrade cannot be applied immediately, disable the IBM ASM I2O interface or block malformed dot command submissions from privileged processes, and enforce strict validation of command sizes to prevent over-read.

Generated by OpenCVE AI on May 27, 2026 at 18:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 27 May 2026 18:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-68

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description 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.
Title ibmasm: fix heap over-read in ibmasm_send_i2o_message()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T12:57:30.247Z

Reserved: 2026-05-13T15:03:33.095Z

Link: CVE-2026-46064

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:26.867

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-46064

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T18:15:21Z

Weaknesses