CVE-2026-81005 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
ipmi: si: Fix NULL pointer dereference after failed registration
try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi().
During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). 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, ipmi_add_smi() logs "Unable to get the device id" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure:
ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5
For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL.
However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg 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 start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler]
RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si]
Call Trace: start_next_msg+0x50/0x80 [ipmi_si]
check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si]
sender+0x69/0x80 [ipmi_si]
i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler]
__get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler]
__bmc_get_device_id+0xef/0x950 [ipmi_msghandler]
redo_bmc_reg+0x52/0x60 [ipmi_msghandler]
process_one_work+0x1a7/0x360
Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in the Linux kernel involves a NULL pointer dereference within the Intelligent Platform Management Interface (IPMI) subsystem, specifically affecting the System Interface (SI) driver code path during device initialization. This issue arises from an improper handling of error conditions when registering an IPMI interface with the system's BMC management controller. The root cause lies in a race condition and state inconsistency between the asynchronous work queue mechanism used for retrying failed operations and the synchronous shutdown routine invoked upon registration failure. When the kernel attempts to initialize an IPMI device, it allocates necessary structures including the SI state machine data before attempting to register the interface with the upper-level message handler. If the BMC fails to respond correctly to a Get Device ID command during this process, the registration function triggers an error handling path that cleans up resources but leaves critical synchronization flags unset, leading to use-after-free or NULL pointer access scenarios when asynchronous retries occur concurrently.
The technical flaw manifests in the try_smi_init function sequence where ipmi_register_smi_mod is called. This maps internally to ipmi_add_smi which attempts to retrieve initial BMC device information via __bmc_get_device_id. If this operation fails due to a non-zero completion code from the hardware, resulting in an -EIO error after retries, the kernel logs Unable to get the device id and proceeds to the out_err_started label. At this stage, shutdown_smi is invoked as part of the cleanup process for ipmi_si drivers. This function correctly frees smi_info->si_sm and sets both si_sm and intf pointers to NULL to prevent further access during normal operation. However, a critical oversight exists in that the intf->in_shutdown flag is not set on this specific error rollback path. Consequently, the asynchronous redo_bmc_reg work item remains active or may be scheduled again by other parts of the subsystem without awareness that the underlying driver state has been destroyed.
This lack of synchronization allows the redo_bmc_reg worker to execute after the lower driver's data structures have already been freed and nullified. The worker attempts to probe the BMC device ID again, invoking __bmc_get_device_id which eventually calls start_next_msg within the SI layer. Since si_sm was set to NULL by the previous shutdown callback, passing this pointer to state machine handlers such as start_kcs_transaction results in a kernel panic due to dereferencing a NULL address at memory location 0x0000000000000000. The stack trace confirms that execution flows through sender and i_ipmi_request before crashing, demonstrating how asynchronous background tasks can interact destructively with cleaned-up resources if proper state flags are not maintained to block such operations during teardown sequences.
From a security perspective, this vulnerability represents a classic use-after-free or NULL pointer dereference issue classified under CWE-476: NULL Pointer Dereference and potentially CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization depending on the exact timing of thread execution. In terms of MITRE ATT&CK mapping, while primarily a stability defect rather than an exploit vector for privilege escalation in most contexts, it aligns with techniques related to Denial of Service via resource exhaustion or system crash if triggered repeatedly by malicious hardware responses or automated fuzzing tools targeting kernel interfaces. The impact includes immediate system instability leading to kernel oops messages and potential reboots, disrupting availability of IPMI-based management capabilities which are critical for remote server administration in enterprise environments.
Mitigation strategies involve applying the upstream patch that sets intf->in_shutdown before invoking the lower driver's shutdown callback on the out_err_started path. This ensures that any subsequent attempts by asynchronous workers like redo_bmc_reg to access interface resources will be blocked because they check this flag prior proceeding with operations. Administrators should ensure their Linux kernels are updated to versions containing this fix, particularly those running IPMI drivers in environments where BMC hardware might return inconsistent or erroneous responses during initialization phases. Additionally, monitoring kernel logs for Unable to register device errors can help identify systems susceptible to these race conditions until patches are deployed across the infrastructure.