Linux kernel ipmi_si: NULL pointer dereference after a failed IPMI interface registration

UnscoredCVE-2026-81005Firmware, BMC & network fabriccurated

Impact

When the BMC does not answer Get Device ID, ipmi_add_smi() fails and calls the low-level shutdown callback, which frees smi_info->si_sm and NULLs it. intf->in_shutdown is never set on that rollback path, so the asynchronous redo_bmc_reg work item can still run afterwards and passes the NULL state-machine pointer into start_kcs_transaction(), panicking the host. The trigger is a BMC that is wedged, mid-reset or slow during boot - a routine condition on a dense GPU node where the service processor is also driving fan and power telemetry. The failure lands at driver init, so the cost is a host that will not come up cleanly rather than a running workload lost, but it turns a recoverable BMC glitch into a node that needs hands-on attention.

Who can reach it

Local and hardware-driven: the host's own BMC returning a nonzero completion code to Get Device ID during ipmi_si probe. No user login and no network reachability to the host are required; anyone able to reset or wedge the BMC over the management VLAN is in a position to induce it.

What to do

Pick up the stable kernel with commit 53af3a8bae0a (or the equivalent backport) and reboot the node; the fix is in the driver init path so a running kernel cannot be corrected in place. Where a kernel update is not imminent, not auto-loading ipmi_si on nodes whose BMC is unstable avoids the path, at the cost of losing in-band IPMI.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-81005 https://git.kernel.org/stable/c/53af3a8bae0a93c1342e1b5519812203332aca8e https://git.kernel.org/stable/c/6d920a75df9a83ab096b3cde7a643b656e4fdfeb https://git.kernel.org/stable/c/8ada17dd4c4ffd6b94621e735d77eda196ce118f

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.