CVE-2026-45994

What it actually does

This is a local Linux kernel memory-safety flaw in the ibmasm driver’s command_file_write() path. A user who can write to the ibmasm command interface can provide a buffer whose actual write length is smaller than the command and data sizes declared in the dot-command header. Because the driver previously trusted those header fields without first confirming the copied buffer was large enough, later parsing can read beyond the allocated kernel buffer and pass out-of-bounds data through memcpy_toio() to the IBM service processor. The primary technical effects are kernel heap memory disclosure to the service processor and potential kernel fault or denial of service. Integrity impact is not expected from the described bug.

Why it matters to the business

Systems using the affected Linux kernel driver on IBM hardware may expose sensitive kernel memory to the platform management/service processor or experience crashes if a local user or compromised low-privileged account abuses the flaw. The vulnerability is local-only, has low current EPSS, no known public exploit maturity, and is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, it remains important for multi-user servers, shared compute platforms, and environments where local compromise could be used to collect secrets or disrupt operations.

How an attack unfolds

An attacker first obtains local code execution on a system where the ibmasm driver is present, loaded, and exposes a writable command interface. The attacker opens that interface and writes a deliberately malformed dot command: the supplied write length is small, but the embedded command_size and/or data_size fields claim a larger total command. The kernel allocates a buffer matching only the attacker-controlled write length and copies in the short user buffer. Vulnerable code then calculates command size and timeout from the untrusted header without validating that the declared command and data payloads fit inside the allocation. As a result, the driver reads past the end of the kernel allocation and performs an out-of-bounds memcpy_toio() toward the service processor. Depending on memory layout and runtime hardening, this can leak adjacent kernel heap contents to the service processor or trigger a kernel warning, fault, or panic that disrupts the host.

How to fix it

Update to a vendor-supplied Linux kernel release that includes the ibmasm bounds-check fix. The corrected logic rejects writes smaller than the dot-command header before allocation and rejects commands where the copied buffer is smaller than sizeof(header) + command_size + data_size after the user data is copied. No exact upstream or distribution fixed versions were provided in the input, so use the relevant Linux distribution or appliance vendor advisory to identify the first fixed kernel package. For custom kernels, backport the ibmasm patch that adds both size checks in command_file_write(). If immediate patching is not possible, reduce exposure by unloading or blocklisting the ibmasm module where it is not required, restricting permissions to any ibmasm command device or filesystem node, and using mandatory access controls to limit which local processes can write to the interface.

How to confirm the fix worked

Confirm the running kernel is a fixed vendor build or that the source/binary contains the added command_file_write() validations for minimum header size and total declared command size. Verify whether the ibmasm module is loaded using standard module inventory commands and confirm that non-administrative users cannot write to the ibmasm command interface. On patched test systems, malformed short dot-command writes should be rejected safely without kernel warnings, KASAN reports, Oops messages, or service disruption. For package-managed systems, validate both the installed kernel package version and the actively booted kernel version, since systems can remain vulnerable after installation until rebooted into the fixed kernel.

Typical attack path

1. Gain local access to an affected Linux host, such as through a shell, compromised service account, or malicious local workload.
2. Confirm the ibmasm driver is loaded and that the attacker’s context can write to the ibmasm command interface.
3. Craft a dot-command buffer whose actual byte count is smaller than sizeof(struct dot_command_header) plus the header-declared command_size and data_size values.
4. Write the malformed buffer to the ibmasm command interface.
5. Trigger the vulnerable parsing path in command_file_write(), causing get_dot_command_size(), get_dot_command_timeout(), or the subsequent memcpy_toio() operation to access memory beyond the allocated buffer.
6. Collect leaked information via the service-processor side if accessible, or use repeated malformed writes to attempt to crash or destabilize the kernel.

How to detect it

Retrospective exploitation detection is difficult because successful abuse may only move kernel heap bytes to the service processor and may not create normal application logs. Focus on kernel telemetry, audit logs, EDR process activity, and service-processor management logs where available. Search for kernel warnings, Oopses, panics, KASAN reports, or slab out-of-bounds messages referencing the ibmasm driver or its command parsing functions. If Linux auditd, eBPF, or EDR file-access telemetry was enabled, look for unusual processes opening or writing to ibmasm-related command interfaces, especially processes that are not expected hardware-management agents. Investigate any correlation between such writes and kernel instability, host reboots, service-processor events, or unexplained management-controller traffic. Absence of these artifacts does not rule out exploitation, especially if the malformed command did not crash the kernel and service-processor-side logs are unavailable.

• ibmasm
• command_file_write
• get_dot_command_size
• get_dot_command_timeout
• memcpy_toio
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in command_file_write
• Out of bounds memory access in ibmasm
• kernel BUG at drivers/misc/ibmasm
• Oops:
• general protection fault
• Kernel panic - not syncing

What your security team should do

• Prioritize patching affected IBM/Linux systems where untrusted local users, shared workloads, or exposed application accounts may obtain local execution.
• Inventory systems for the ibmasm driver and identify whether it is loaded, enabled at boot, or required for operations.
• If the driver is not operationally required, unload it and blocklist it pending patch deployment.
• Restrict write access to ibmasm command interfaces to the smallest possible set of privileged management processes.
• Add audit or EDR monitoring for unexpected local processes opening or writing to ibmasm-related device or filesystem nodes.
• Review kernel logs for Oops, panic, KASAN, or slab out-of-bounds reports involving ibmasm, command_file_write(), get_dot_command_size(), get_dot_command_timeout(), or memcpy_toio().
• Because there is no KEV listing, no known ransomware association, and very low EPSS at publication-plus-76-days, handle as a local hardening and kernel maintenance priority rather than an emergency internet-facing exposure unless the system is multi-tenant or high-sensitivity.