CVE-2026-46044

What it actually does

This is a local denial-of-service flaw in the Linux kernel IPMI SSIF driver. If SSIF initialization fails after the driver creates its worker kernel thread but before the IPMI core fully starts the interface, the error path can leave that kernel thread running instead of stopping it. A local user with the ability to influence or trigger the relevant IPMI SSIF driver initialization path could cause leaked kernel-thread activity and resource consumption, potentially degrading system availability or contributing to a crash/hang depending on system configuration and repeated triggering. The issue affects availability only; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems that use Linux kernel IPMI SSIF support, commonly server platforms with BMC/IPMI management integrations, may be vulnerable to local availability disruption. Successful exploitation could cause operational instability on affected servers, interfere with hardware management functions, or require a reboot to recover. The current EPSS is very low, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, organizations running multi-user Linux systems, shared compute, hosting platforms, or environments where local users can load or trigger affected driver paths should prioritize patching according to normal kernel maintenance cycles.

How an attack unfolds

An attacker first needs local access with sufficient privileges or environmental control to exercise the IPMI SSIF driver initialization path, such as by causing the affected module or device path to be initialized on hardware where SSIF is present or emulated. The attacker then induces an error condition after the SSIF kernel thread is created but before the interface is fully started by the main IPMI code. In vulnerable kernels, the cleanup logic fails to stop the already-created thread. By repeatedly triggering this initialization failure path, the attacker may leave behind running kernel threads or associated resources, degrading availability and potentially leading to system instability. There is no indication from the provided data that this issue enables remote code execution, privilege escalation, data theft, or ransomware activity.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream fix for the IPMI SSIF cleanup error path. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor for CVE-2026-46044. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the IPMI SSIF driver if it is not required, restricting local shell access, limiting module-loading capabilities, and ensuring only trusted administrators can manage kernel modules and hardware-management interfaces. Potential mitigations include blacklisting the affected driver module where operationally safe, for example by disabling `ipmi_ssif`, but this should be validated first because it may affect BMC/IPMI management functionality.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor fix for the IPMI SSIF kthread cleanup issue, not merely that an updated package is installed on disk. Reboot into the patched kernel if required. Check whether the affected functionality is present by reviewing loaded modules and kernel configuration for IPMI SSIF support, such as `lsmod`, `/proc/modules`, `/sys/module/`, and distribution kernel package metadata. Validate that `ipmi_ssif` is either patched or not loaded where it is not needed. For mitigation validation, confirm the module cannot be loaded by unprivileged users and that any blacklist or kernel module policy is active after reboot. If a test environment is available, exercise SSIF initialization failure handling and confirm that failed initialization does not leave persistent SSIF-related kernel threads behind.

Typical attack path

1. Gain local access to a Linux system that includes the affected kernel IPMI SSIF driver and where the SSIF initialization path can be reached.
2. Identify whether IPMI SSIF support is present, enabled, or loadable on the target system.
3. Trigger SSIF driver initialization while creating or relying on an error condition before the IPMI core fully starts the interface.
4. Cause the vulnerable cleanup path to execute, leaving the SSIF kernel thread running instead of stopping it.
5. Repeat the trigger to consume kernel resources or create instability, resulting in degraded service, hangs, or denial of service.

How to detect it

To assess possible prior exploitation, review host telemetry rather than network logs, because the vulnerability requires local interaction with the kernel driver path. Examine kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, and audit logs for repeated IPMI SSIF driver initialization errors, repeated loading or unloading of IPMI-related modules, and bursts of failures involving `ipmi_ssif`, `ipmi_devintf`, `ipmi_msghandler`, or SSIF/I2C device initialization. Look for anomalous local user activity around `modprobe`, `insmod`, `rmmod`, hardware-management tooling, or scripts repeatedly interacting with IPMI modules. On systems with process accounting or EDR telemetry, search for repeated execution of module-management commands by non-administrative accounts. Also inspect for unexpected or excessive kernel threads with SSIF/IPMI-related names after failed initialization attempts. There are no known public exploit artifacts or threat-actor-specific indicators from the provided data, so detection should focus on repeated error-path triggering and local attempts to manipulate the affected driver.

• ipmi_ssif
• ipmi_devintf
• ipmi_msghandler
• modprobe ipmi_ssif
• insmod ipmi_ssif
• rmmod ipmi_ssif
• /sys/module/ipmi_ssif
• /proc/modules
• /var/log/kern.log
• /var/log/messages
• IPMI SSIF
• ssif

What your security team should do

• Inventory Linux systems that enable IPMI/BMC management support and check whether the `ipmi_ssif` driver is present or loaded.
• Prioritize kernel updates on shared, multi-user, hosting, HPC, build, and administrative jump systems where local users have access.
• Apply the vendor-provided kernel update containing the IPMI SSIF cleanup fix, then reboot into the fixed kernel where required.
• If IPMI SSIF is not operationally required, disable or blacklist the `ipmi_ssif` module after confirming there is no dependency on SSIF-based management.
• Restrict local access and kernel module management privileges to trusted administrators only.
• Monitor kernel logs for repeated IPMI SSIF initialization failures, repeated module load/unload activity, or unusual growth in kernel threads related to IPMI/SSIF.
• Because the issue is not in KEV and EPSS is low, treat this as a defense-in-depth availability fix unless local exploitation risk is elevated in the environment.