CVE-2026-46128

What it actually does

This is an improper input validation flaw in the Linux kernel IPMI subsystem. The kernel did not validate the size or presence of event message buffer response data immediately after receiving it from a Baseboard Management Controller. If a BMC returned an empty or malformed response instead of an error, later kernel processing could operate on invalid data and cause a kernel fault or crash. The assessed impact is primarily local denial of service: a low-privileged local user who can cause IPMI event-buffer retrieval may be able to trigger a system availability failure. There is no indicated confidentiality or integrity impact from the published metadata.

Why it matters to the business

Affected Linux systems with IPMI support may be vulnerable to local denial-of-service conditions that can crash or destabilize servers. The business impact is highest for physical or virtual infrastructure that depends on in-band IPMI monitoring, fleet health tooling, or hardware management integrations, because a crash can interrupt workloads, monitoring, and service availability. This issue is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the supplied data, so it should be prioritized as a normal kernel stability/security update unless the organization exposes IPMI functionality to untrusted local users or runs high-availability workloads on affected kernels.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel and a path to exercise IPMI event message handling, such as access to IPMI device interfaces, management utilities, or another local mechanism that causes the kernel IPMI driver to fetch event-buffer data from the BMC. The attacker then induces or relies on a BMC response that is empty or otherwise shorter than expected. Because the vulnerable kernel validates the response too late, malformed response data can reach later processing paths and trigger a kernel error. Successful exploitation is expected to result in denial of service, such as a kernel oops, panic, system hang, or reboot, rather than code execution or data theft based on the available description.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream IPMI fix for validating event message buffer response data immediately after the response is received. No exact fixed package versions were provided, so use vendor advisories, distribution security trackers, and kernel changelogs referencing the IPMI event message buffer validation fix. After patching, reboot into the updated kernel and confirm the older affected kernel is no longer running. Where immediate patching is not possible, reduce exposure by restricting local access to IPMI device nodes and management utilities, limiting membership in groups that can access /dev/ipmi* devices, disabling unnecessary in-band IPMI functionality where operationally acceptable, and ensuring workload failover is available for systems that may be destabilized by kernel crashes.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release containing the fix, not merely that a package is installed. Validate with commands such as uname -a, package-manager kernel version checks, and vendor advisory mapping. Check whether IPMI is present or loaded using lsmod, modinfo, dmesg, and the presence of /dev/ipmi* device nodes. Review distribution kernel changelogs for the IPMI fix described as validating event message buffer response data or handling empty BMC event responses. If testing in a lab, exercise normal IPMI event retrieval after patching and verify the host remains stable and logs no kernel oops, panic, or IPMI response-length errors. Avoid destructive proof-of-concept testing on production systems because the expected failure mode is service disruption.

Typical attack path

1. Gain local access to a Linux host running an affected kernel with IPMI support enabled or available.
2. Identify whether IPMI device interfaces, kernel modules, or local management tools can be used to request event message buffer data.
3. Trigger IPMI event-buffer retrieval through local tooling or device interaction.
4. Cause, induce, or encounter an empty or malformed BMC event message buffer response.
5. The kernel IPMI code processes insufficiently validated response data.
6. The system experiences a kernel fault, panic, hang, reboot, or related availability failure.

How to detect it

Because this issue is expected to cause denial of service rather than a persistent compromise, detection should focus on evidence of attempted IPMI interaction followed by kernel instability. Review kernel logs, system journals, crash dumps, BMC/system event logs, audit logs, and command execution telemetry. Look for kernel oops or panic traces involving IPMI components such as ipmi_msghandler, ipmi_si, ipmi_devintf, or event message buffer processing, especially when followed by reboot, watchdog reset, or host unavailability. Review auditd, sudo, shell history, and EDR telemetry for local use of IPMI utilities such as ipmitool near the time of a crash. Correlate host reboot timelines with BMC SEL entries and kernel crash artifacts under /var/crash or kdump storage. Since no public exploit or threat actor activity is indicated in the supplied data, absence of these artifacts does not prove safety, but repeated IPMI-related kernel faults or unexplained reboots should be investigated as possible exploitation or triggering of this bug.

• /dev/ipmi0
• /dev/ipmi1
• /dev/ipmi2
• ipmitool
• ipmi_msghandler
• ipmi_si
• ipmi_devintf
• ipmi_poweroff
• ipmi_watchdog
• event message buffer
• kernel panic
• kernel oops
• Oops:
• BUG: kernel NULL pointer dereference
• general protection fault
• watchdog: BUG: soft lockup
• watchdog: hard LOCKUP
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/modules
• /sys/module/ipmi_msghandler
• /sys/module/ipmi_si
• /sys/module/ipmi_devintf

What your security team should do

• Patch affected Linux kernels through the appropriate OS vendor channel and reboot systems into the fixed kernel.
• Prioritize servers where IPMI is enabled, BMC integration is actively used, or local shell access is available to many users.
• Restrict access to /dev/ipmi* and IPMI management tools to trusted administrators only.
• Review sudo, group membership, container, and service-account permissions that could allow untrusted users to interact with IPMI device interfaces.
• Monitor for kernel oops, panic, watchdog reset, or unexpected reboot events involving IPMI modules.
• If patching is delayed, consider disabling unused in-band IPMI kernel modules or blacklisting IPMI access where operationally safe.
• For high-availability services, verify failover and restart procedures because exploitation or accidental triggering may cause host-level downtime.