CVE-2026-46177

What it actually does

This flaw affects the Linux kernel IPMI driver. Before the fix, the driver could repeatedly fetch IPMI events or received messages from the Baseboard Management Controller without a bounded limit if the BMC continually indicated that more data was available, or if the IPMI system interface attention state remained stuck. A faulty, compromised, or maliciously influenced BMC could therefore cause the kernel IPMI path to loop excessively, consume CPU, delay other kernel work, or degrade host availability. The fix adds bounded fetch limits and allows message handling between flag fetches so the driver does not become trapped servicing an unending BMC condition.

Why it matters to the business

The primary risk is outage or severe performance degradation of Linux systems that use IPMI/BMC management. Affected systems may become slow, unstable, or require manual recovery if the kernel spends excessive time handling never-ending management-controller events. This is especially relevant for servers where IPMI is enabled for out-of-band administration. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is not indicated; however, management interfaces are high-value infrastructure, and a compromised or malfunctioning BMC can still create operational impact.

How an attack unfolds

An attacker would first need a way to influence the BMC or the IPMI path used by the Linux host. In practice, this could mean compromising exposed BMC management services, abusing weak IPMI credentials, exploiting a separate BMC firmware issue, or operating from a network segment that can reach the management interface. The attacker then causes the BMC to continually report pending events, received messages, or a stuck attention condition. The vulnerable Linux kernel IPMI driver continues fetching from the BMC without sufficient limits, causing excessive polling or processing in kernel context. The result is a denial of service against the host, ranging from high CPU usage and degraded responsiveness to service interruption or the need to reboot. The same symptoms can also occur without a malicious actor if a buggy BMC firmware implementation never reports completion correctly.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the IPMI driver fix adding limits to event and receive-message fetches. No exact fixed package versions were provided in the input, so use vendor advisories for the affected distribution and kernel stream. Also update BMC firmware, because this flaw is triggered by BMCs that repeatedly claim to have data or remain in an attention state. If IPMI is not required, disable the IPMI kernel modules and related services. Restrict IPMI/BMC access to a dedicated management network, block access from untrusted networks, enforce strong unique credentials, and disable unused BMC services. As temporary mitigations, isolate affected BMC interfaces, reset or update malfunctioning BMCs, and reboot impacted hosts only after removing the triggering BMC condition where possible.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the IPMI fetch-limiting fix. Validate through distribution package metadata, kernel changelogs, or advisory references rather than relying only on the upstream version string. Check whether IPMI modules such as ipmi_si and ipmi_msghandler are loaded on systems where IPMI is expected or not expected. Review dmesg and journal logs after patching to ensure the system no longer shows repeated IPMI polling, hung task, watchdog, or soft lockup symptoms during BMC event activity. Where safe, perform controlled validation with a test BMC or lab system that produces repeated IPMI events and verify that the host remains responsive. Also confirm BMC firmware is current and that BMC/IPMI services are not reachable from untrusted networks.

Typical attack path

1. Identify Linux servers using IPMI/BMC management interfaces.
2. Gain the ability to interact with or influence the BMC, such as through exposed management services, stolen IPMI credentials, weak configuration, or another BMC vulnerability.
3. Cause the BMC to continuously indicate pending events, received messages, or an attention state that does not clear.
4. Trigger the Linux IPMI driver to repeatedly service those BMC indications.
5. Force excessive kernel-side IPMI processing, leading to CPU consumption, degraded responsiveness, or host-level denial of service.
6. Maintain or repeat the condition until the system is patched, the BMC behavior is corrected, IPMI access is blocked, or the host is recovered.

How to detect it

To determine whether this was already exploited or triggered, review host kernel logs, system journals, BMC event logs, BMC authentication logs, management-network firewall logs, and performance telemetry. Look for time-correlated evidence of repeated IPMI activity, kernel watchdog warnings, soft lockups, hung tasks, high CPU usage by IPMI-related kernel threads, loss of host responsiveness, or BMC event storms. Investigate BMC-side signs such as unexpected logins, failed login bursts, configuration changes, firmware changes, resets, or unusual traffic to IPMI/RMCP, Redfish, HTTPS, SSH, or other management services. Because the same failure mode can result from buggy BMC firmware, distinguish malicious exploitation from malfunction by correlating symptoms with management-interface access logs, credential use, network source addresses, and any recent BMC firmware or configuration changes. There are no public threat actors or campaigns identified in the input for this vulnerability.

What your security team should do

• Prioritize patching Linux servers that use IPMI/BMC management, especially internet-adjacent, externally managed, or high-availability infrastructure.
• Update BMC firmware in parallel with the OS kernel update to reduce the chance of recurring malformed or stuck BMC behavior.
• Audit exposure of IPMI, Redfish, web management, SSH, SNMP, and other BMC services; restrict them to dedicated management networks and trusted administration hosts.
• Review BMC authentication controls, remove default credentials, rotate shared credentials, and enable logging where supported.
• Identify systems with loaded IPMI kernel modules and confirm whether IPMI is required; disable IPMI components where there is no operational need.
• Monitor for host availability symptoms such as high kipmi activity, soft lockups, watchdog events, repeated IPMI event handling, and unexpected BMC resets or login activity.
• Because this is not KEV-listed and has low EPSS, sequence remediation according to asset criticality and BMC exposure rather than treating it as evidence of active widespread exploitation.