CVE-2026-46108

What it actually does

This is a local denial-of-service flaw in the Linux kernel IPMI system-interface driver. When message allocation fails in certain IPMI paths, the driver may not restore its state machine to a normal operating state. A low-privileged local user who can trigger IPMI activity and create memory-allocation pressure may cause IPMI communication to stall or become unavailable, affecting local management, monitoring, or hardware-control functions that rely on the kernel IPMI driver. The vulnerability does not provide confidentiality or integrity impact, and there is no indication of remote code execution or privilege escalation from the supplied data.

Why it matters to the business

Systems that depend on IPMI for hardware monitoring, remote management, watchdog functions, or out-of-band operational workflows may lose those capabilities until the driver or host is recovered. The practical risk is operational disruption rather than data theft. The CVSS availability impact is high, but current exploitation likelihood appears low: EPSS is 0.00123, it is not listed in CISA KEV, there is no known ransomware association, and exploit maturity is listed as none. Organizations with large Linux server fleets, bare-metal infrastructure, appliances, or monitoring platforms that rely on IPMI should still prioritize remediation through normal kernel maintenance because a local user or compromised low-privilege account could use the flaw to degrade manageability.

How an attack unfolds

An attacker first needs local execution with low privileges on a Linux system using the affected kernel IPMI system-interface driver. The attacker then causes IPMI message activity, for example through local IPMI device interfaces or tools that communicate with the kernel IPMI driver, while also creating conditions where kernel message allocation can fail, such as memory pressure. In vulnerable kernels, an allocation failure may leave the IPMI SI driver in a non-normal state instead of cleanly recovering. Once the state machine is stuck, subsequent IPMI operations may not start or complete, causing management and monitoring components that rely on IPMI to fail or hang. Recovery may require restarting dependent services, unloading/reloading the driver where safe, or rebooting the host depending on platform behavior.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the IPMI SI fix for returning the driver to a normal state when message allocation fails. No exact fixed package versions were provided, so use the vendor advisory, changelog, or package metadata for the deployed distribution to identify the corrected kernel build. Reboot into the updated kernel after installation and verify that the running kernel, not only the installed package, is fixed. Where immediate patching is not possible, reduce exposure by restricting access to local IPMI character devices, limiting use of IPMI tooling to trusted administrators, applying least-privilege controls and audit rules around /dev/ipmi* access, constraining untrusted workloads with cgroups or container isolation, and disabling or unloading the ipmi_si driver only if IPMI functionality is not required and doing so is operationally safe.

How to confirm the fix worked

Confirm remediation by checking the running kernel version with uname -r and comparing it against the fixed kernel version listed by the applicable Linux distribution or appliance vendor. Review kernel package changelogs for the IPMI SI fix described as returning state to normal when message allocation fails. Verify that the host has rebooted into the patched kernel after the update. Functional validation should include exercising normal IPMI operations, such as sensor reads or BMC communication through approved tools, and confirming that repeated operations continue to complete successfully under normal load. Exposure validation should check whether ipmi_si is loaded, whether /dev/ipmi* devices exist, and whether untrusted users or workloads can access them.

Typical attack path

1. Obtain low-privileged local access to a Linux host that loads the affected IPMI system-interface driver.
2. Confirm that local IPMI device interfaces or IPMI tooling are available, such as /dev/ipmi0, /dev/ipmi/0, or ipmitool.
3. Generate IPMI message activity against the kernel IPMI driver.
4. Create memory-allocation pressure or otherwise force an IPMI message allocation failure.
5. Trigger the vulnerable path where the driver fails to return its internal state to normal.
6. Cause IPMI communication, hardware monitoring, watchdog, or management workflows to stall or fail until recovery actions are taken.

How to detect it

There is unlikely to be a single definitive log entry proving exploitation because the issue manifests as an IPMI driver state failure after allocation failure and can resemble ordinary resource exhaustion or driver instability. To assess whether it was already exploited, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and /var/log/syslog for IPMI SI errors, allocation failures, memory pressure, hung IPMI operations, or hardware-monitoring failures. Correlate those events with auditd, EDR, shell history, sudo logs, and process execution telemetry showing local use of ipmitool or other programs opening /dev/ipmi* devices. Also inspect authentication logs for new or unusual local sessions before the IPMI failure. If audit rules are available, search for open, ioctl, or write activity against /dev/ipmi0, /dev/ipmi/0, or /dev/ipmi/1 by non-administrative users. Forensic triage should focus on the timeline of memory pressure, IPMI device access, failed sensor or BMC reads, and subsequent recovery actions such as driver reloads or reboots.

• ipmi_si
• ipmi:si
• /dev/ipmi0
• /dev/ipmi/0
• /dev/ipmi/1
• ipmitool
• page allocation failure
• Out of memory
• allocation failure
• hung task
• ipmi_si_drv
• modprobe ipmi_si
• rmmod ipmi_si
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems that load the ipmi_si or related IPMI kernel modules, prioritizing bare-metal servers, appliances, monitoring nodes, and systems that rely on hardware watchdog or BMC integration.
• Patch affected systems through the normal kernel update process and reboot into the corrected kernel.
• Because no fixed versions were supplied, track distribution-specific advisories and verify the exact fixed kernel build per operating system release.
• Restrict access to /dev/ipmi*, IPMI management tools, and any local groups that grant hardware-management access.
• Add audit or EDR monitoring for unusual local access to IPMI devices, repeated ipmitool execution, and memory-pressure events occurring near IPMI failures.
• For systems that do not require host IPMI access, consider disabling the ipmi_si driver after validating operational impact.
• Treat suspicious exploitation attempts as a local-post-compromise signal and investigate the source account, process tree, and preceding authentication activity.
• Monitor vendor advisories for any change in exploit maturity, EPSS movement, or KEV status.