CVE-2026-46022

What it actually does

This vulnerability is an out-of-bounds memory-mapped I/O read in the Linux kernel ibmasm driver, specifically in ibmasm_handle_mouse_interrupt(). The driver trusts queue reader and writer index values supplied by hardware through MMIO registers and uses them to calculate an address inside a remote input queue without first verifying that the indices are below REMOTE_QUEUE_SIZE. If a compromised or malicious service processor supplies an out-of-range index and triggers an interrupt, the kernel may read 8 bytes from unintended device registers or, for larger index values, access outside the mapped PCI BAR region. The likely outcomes are kernel memory disclosure from unintended MMIO locations and system instability, including a machine check exception or crash.

Why it matters to the business

Systems using affected Linux kernels with the IBM Advanced System Management driver exposed to a compromised service processor may suffer unexpected crashes or hardware-level fault conditions, causing service interruption. Because exploitation requires local-level conditions and control of or influence over the service processor/MMIO state, broad internet-scale exploitation is unlikely based on the current low EPSS score and no known KEV listing. However, the impact can still be significant for high-availability Linux servers because successful exploitation can disclose sensitive low-level device data or cause abrupt system failure.

How an attack unfolds

An attacker first needs a position that allows them to influence the IBM service processor or the MMIO registers consumed by the ibmasm driver. From there, the attacker writes an invalid reader or writer queue index greater than or equal to the queue size, then causes or waits for a mouse/input-related interrupt handled by ibmasm_handle_mouse_interrupt(). The vulnerable kernel path reads the untrusted index directly from MMIO and uses it in pointer arithmetic to locate a queue entry. Because the value is not bounds-checked before use, the calculated MMIO address can point outside the intended queue. The kernel then calls memcpy_fromio() and reads from that unintended address. Depending on the chosen index and the platform behavior, this can return unintended device data or trigger a machine check exception, resulting in a kernel crash or system outage.

How to fix it

Upgrade to a Linux kernel version that includes the ibmasm bounds-checking fix for ibmasm_handle_mouse_interrupt(). Because exact fixed package versions were not provided, use the security advisories from the relevant Linux distribution or kernel vendor and confirm that the applied kernel contains the patch that validates both reader and writer indices against REMOTE_QUEUE_SIZE before calling get_queue_entry(), and resets the reader register on invalid values. Where immediate patching is not possible, reduce exposure by disabling or unloading the ibmasm driver if it is not required, restricting access to service processor management interfaces, applying service processor firmware updates, segmenting management networks, and monitoring for machine-check or kernel oops events associated with ibmasm activity. Reboot into the patched kernel after installation; simply installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, using uname -a and compare it against the distribution advisory that includes the fix. Check whether the ibmasm driver is present or loaded using lsmod, modinfo ibmasm, and kernel configuration/package metadata. If source validation is possible, verify that ibmasm_handle_mouse_interrupt() checks both queue reader and writer indices against REMOTE_QUEUE_SIZE before calling get_queue_entry() or memcpy_fromio(). After remediation, confirm the host has rebooted into the patched kernel and that no vulnerable ibmasm module remains loaded. For mitigation validation, confirm the ibmasm module is blocked or unloaded on systems that do not need it, and confirm service processor management access is limited to trusted administrative networks.

Typical attack path

1. Obtain local privileged hardware-adjacent access, service processor compromise, or another position capable of manipulating the relevant ibmasm MMIO registers.
2. Write an out-of-range value to the queue reader or writer MMIO register used by the ibmasm remote input queue.
3. Assert, trigger, or wait for an interrupt that invokes ibmasm_handle_mouse_interrupt().
4. Allow the vulnerable handler to calculate a queue entry address using the unvalidated index.
5. Cause the kernel to read 8 bytes from an unintended MMIO address via memcpy_fromio().
6. Leverage the result as a device/MMIO information disclosure or force an access outside the PCI BAR mapping to crash the system.

How to detect it

Detection should focus on signs of attempted malformed MMIO queue manipulation and resulting kernel instability. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for ibmasm driver activity, machine check exceptions, kernel oopses, general protection faults, PCI/MMIO access errors, and abrupt reboots. Also review service processor, BMC, or hardware management logs for unexpected remote console, input, firmware, or management-controller activity before the crash. Because the vulnerability is triggered through hardware/MMIO state rather than a conventional network request, there may be no application-layer or network IOC. Correlate system crashes with ibmasm module loading, service processor events, and remote management access. If kdump/vmcore data is available, inspect stack traces for ibmasm_handle_mouse_interrupt(), memcpy_fromio(), machine_check, or PCI/MMIO fault paths.

• ibmasm_handle_mouse_interrupt
• ibmasm
• memcpy_fromio
• Machine check exception
• mce:
• Kernel panic
• Oops:
• BUG: unable to handle kernel
• general protection fault
• PCI BAR
• MMIO
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/modules
• lsmod | grep ibmasm
• modinfo ibmasm

What your security team should do

• Inventory Linux systems that include or load the ibmasm driver, prioritizing IBM server platforms and systems with service processor management enabled.
• Patch affected kernels using vendor-provided security updates and reboot systems into the fixed kernel.
• If ibmasm functionality is not required, disable or blacklist the ibmasm module as a compensating control.
• Restrict and monitor service processor management interfaces, including out-of-band management networks, because exploitation depends on influence over hardware-provided queue indices.
• Review kernel logs for machine check exceptions, kernel oopses, PCI BAR/MMIO access faults, and ibmasm-related errors that may indicate attempted exploitation or unstable service processor behavior.
• Track distribution advisories for exact fixed package versions, since upstream kernel fixes may be backported under vendor-specific version numbers.
• Treat unexplained crashes on systems using ibmasm as potentially security-relevant until hardware logs, service processor logs, and kernel logs are reviewed.