CVE-2026-46064

What it actually does

CVE-2026-46064 is a Linux kernel heap over-read in the IBM Advanced System Management driver path, specifically ibmasm_send_i2o_message(). The vulnerable code calculates a memcpy_toio() length from user-controlled dot_command_header fields without validating that the requested command/data size fits within the buffer actually supplied. A privileged local user can provide a small buffer with inflated size fields, causing the kernel to read beyond the allocated heap object and copy adjacent kernel heap contents over MMIO to the service processor. This can disclose sensitive kernel memory and may also disrupt the service processor/I2O message handling path by exhausting or desynchronizing message frames, producing availability impact.

Why it matters to the business

The practical risk is local privilege-bound exposure of sensitive kernel memory and potential disruption of hardware management functions on systems using the affected ibmasm driver. Because exploitation requires local privileges and there is no known public exploitation or KEV listing, internet-scale exploitation risk is currently low; however, on multi-user Linux systems, shared administrative platforms, or systems where untrusted users can obtain local access, this could aid post-compromise data exposure or destabilize server management capabilities.

How an attack unfolds

An attacker first needs local access with sufficient privileges to interact with the affected ibmasm device/interface. They craft a dot command buffer whose actual allocation is small but whose header fields claim a much larger command_size and/or data_size. When the buffer is passed into the vulnerable kernel driver path, ibmasm_send_i2o_message() trusts those size fields and uses the derived length for memcpy_toio(). The kernel then reads past the end of the attacker-controlled allocation into adjacent kernel heap memory and writes those bytes to the service processor through MMIO. Depending on system behavior and attacker observability of the service processor response or side effects, this may leak kernel-resident data. Malformed or inconsistent message sizing may also desynchronize or exhaust I2O/service-processor message handling resources, leading to management-path instability or denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the ibmasm_send_i2o_message() size-validation issue. Because no exact fixed package versions were provided, use vendor advisories for the specific Linux distribution and kernel stream in use and install the latest available security kernel update. Where immediate patching is not possible, reduce exposure by unloading or disabling the ibmasm driver if IBM Advanced System Management functionality is not required, restricting access to any associated device nodes to trusted administrators only, and preventing untrusted local users or workloads from running on affected hosts. Reboot into the patched kernel after installation; simply installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, includes the fix. Check the active kernel with uname -a and compare it against the distribution’s advisory-fixed kernel version. Verify whether the ibmasm module is loaded with lsmod or modinfo ibmasm; if the driver is not present or not loaded, practical exposure is reduced. If building from source, verify the ibmasm_send_i2o_message() implementation validates dot command sizes against the actual allocation before get_mfa_inbound()/memcpy_toio() and rejects inconsistent command lengths. After remediation, test that malformed dot command inputs with inflated command_size/data_size fields are rejected and do not produce kernel warnings, service processor errors, or I2O frame exhaustion.

Typical attack path

1. Gain local access to a Linux system with the affected ibmasm kernel driver present and usable.
2. Obtain sufficient local privileges to open and write to the ibmasm device or relevant driver interface.
3. Allocate or submit a small dot command buffer containing inflated command_size and/or data_size fields in the dot_command_header.
4. Trigger ibmasm_send_i2o_message() so the kernel calculates an excessive copy length from the attacker-controlled header.
5. Cause memcpy_toio() to over-read adjacent kernel heap memory and forward the copied bytes to the service processor over MMIO.
6. Attempt to recover leaked data through service-processor behavior, responses, logs, or observable side effects, or repeatedly trigger the flaw to cause service-processor/I2O instability.

How to detect it

Look for signs that a local process interacted unusually with the ibmasm driver or caused errors in IBM Advanced System Management/I2O messaging. Relevant sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records for device-node access, EDR process telemetry, and service-processor management logs where available. Search for repeated opens or writes to ibmasm device nodes, kernel warnings or oopses near ibmasm_send_i2o_message(), I2O inbound-frame exhaustion, service processor desynchronization/reset messages, or unexplained instability of hardware management functions. Because this vulnerability is a memory over-read and the copied data is sent over MMIO, there may be no network IOC and no reliable artifact if exploitation succeeds quietly. Focus detection on local access patterns, malformed-command testing behavior, and correlated kernel/service-processor anomalies.

• ibmasm
• ibmasm_send_i2o_message
• get_dot_command_size
• memcpy_toio
• dot_command_header
• INBOUND_QUEUE_PORT
• get_mfa_inbound
• set_mfa_inbound
• I2O_COMMAND_SIZE
• i2o
• service processor
• /dev/ibmasm

What your security team should do

• Prioritize patching affected Linux systems where the ibmasm driver is loaded, IBM service-processor management features are used, or untrusted local users/workloads are present.
• Inventory systems for the ibmasm kernel module using endpoint telemetry, package inventory, lsmod/modinfo results, or kernel configuration data.
• If the driver is unnecessary, disable or blacklist ibmasm and restrict access to related device nodes as a compensating control.
• Review local user access policies on affected systems; exploitation requires local privileged interaction, so reduce unnecessary shell, container, and administrative access.
• Monitor for repeated access to ibmasm device interfaces, kernel warnings involving ibmasm/I2O/service-processor messaging, and unexpected service-processor management instability.
• Track Linux distribution security advisories for exact fixed kernel package versions and ensure systems have rebooted into the updated kernel.