CVE-2026-81005: ipmi: si: Fix NULL pointer dereference after failed registration
In the Linux kernel, the following vulnerability has been resolved:
ipmi: si: Fix NULL pointer dereference after failed registration
trysmiinit() allocates newsmi->sism and later calls ipmiregistersmimod(), which maps to ipmiaddsmi().
During ipmiaddsmi(), the upper IPMI message handler obtains the initial BMC device information through bmcgetdeviceid(). This can fail if the BMC does not return a successful response to the Get Device ID command.
When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched.
On this failure path, ipmiaddsmi() logs "Unable to get the device id" and goes to outerrstarted, where it invokes the lower driver's shutdown callback. trysmiinit() then logs the returned registration failure:
ipmisi IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmisi IPI0001:00: Unable to register device: error -5
For ipmisi, the shutdown callback is shutdownsmi(), which cleans up the SI state machine data, frees smiinfo->sism, and sets smiinfo->sism and smiinfo->intf to NULL.
However, intf->inshutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redobmcreg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached startnextmsg(), which passed the NULL smiinfo->sism pointer to the selected KCS state machine handler:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redobmcreg [ipmimsghandler] RIP: startkcstransaction+0x2c/0x190 [ipmisi] Call Trace: startnextmsg+0x50/0x80 [ipmisi] checkstarttimerthread.part.9+0x3b/0x50 [ipmisi] sender+0x69/0x80 [ipmisi] iipmirequest+0x2ac/0x9d0 [ipmimsghandler] getdeviceid.isra.29+0xaa/0x180 [ipmimsghandler] bmcgetdeviceid+0xef/0x950 [ipmimsghandler] redobmcreg+0x52/0x60 [ipmimsghandler] processonework+0x1a7/0x360
Set intf->inshutdown on the outerrstarted path before invoking the lower driver's shutdown callback. This prevents later redobmcreg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the failure path?
The IPMI SI driver must be initializing, and the BMC must repeatedly fail the Get Device ID command by returning a nonzero completion code. After retries, the device-ID lookup returns -EIO and registration fails.
Which systems are realistically exposed?
Systems using the Linux kernel IPMI SI driver and an IPMI BMC are exposed when the BMC cannot provide successful device identification during initialization. The described log identifies an IPMI SI device such as IPI0001:00.
How can I identify this condition in logs?
Look for "IPMI message handler: Unable to get the device id: -5" followed by "Unable to register device: error -5" from ipmi_si. These messages indicate that BMC device-ID retrieval failed and the registration error path was entered.