Linux Kernel EUVD-2026-32426

Three conditions must align: (1) the target system must have SSIF-capable IPMI hardware - a BMC physically connected via SMBus/I2C bus - without this hardware, the ipmi_ssif module will not probe and the code path is unreachable; (2) the ipmi_ssif kernel module must be loaded or reloading; (3) a specific error condition must occur after the ssif kthread is created but before the IPMI core layer successfully starts the interface - this is not a straightforward attacker-controlled trigger, as it depends on driver initialization state and hardware behavior. Low-privilege local access (PR:L per CVSS) is required at minimum. The 'Information Disclosure' tag in the source intelligence is inconsistent with both the CVE description and CVSS C:N - do not use this tag to scope data-theft risk. Limiting factors: hardware prerequisite (SSIF IPMI BMC), driver-state dependency, and local-only attack vector collectively make this highly resistant to remote or automated exploitation.

Real-world risk is low. The NVD CVSS 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects local-only reach and pure availability impact. EPSS at 0.02% (4th percentile) confirms negligible exploitation probability; there is no CISA KEV listing and no known POC. Notably, the source intelligence tags this as 'Information Disclosure,' which directly conflicts with the CVSS vector showing C:N (no confidentiality impact) and the CVE description's cleanup-defect nature - this tag appears to be a mis-classification and should not influence risk scoping. Triggering the defect requires a specific error condition during driver initialization rather than a directly controllable attacker input, which effectively raises practical attack complexity beyond what AC:L implies in the NVD vector. The availability impact (A:H) is plausible - an orphaned kthread can consume kernel scheduler resources and interfere with clean module unloading or system shutdown - but reliable engineer-able denial-of-service is unlikely without physical or privileged control over the hardware initialization state. Treat this as a normal kernel update priority.

A local user on a server with SSIF-capable IPMI hardware manipulates the SMBus device state or exploits a hardware fault to cause the ipmi_ssif driver's initialization to fail after the ssif kthread has already been created. The cleanup path skips kthread_stop(), leaving the thread running in the kernel indefinitely. Over time, the orphaned thread consumes scheduler resources and prevents clean module unloading, degrading system availability. No public exploit code exists, and reliably triggering the specific error condition requires either privileged access to the driver initialization sequence or physical influence over the BMC hardware.