GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel ipmi_msghandler: work item left scheduled when interface startup fails, freeing live state

UnscoredCVE-2026-81004Firmware, BMC & network fabriccurated

Impact

Every server node with a BMC loads the kernel IPMI stack, and GPU nodes are no exception - it is how the host reads inlet temperature, power draw and sensor state. If an IPMI interface fails part way through startup, the driver frees the interface without cancelling work it has already scheduled, so a queued work item can run against freed memory. The record gives no attacker-controlled trigger: it fires on a startup error, typically from a misbehaving or slow BMC, not from anything a tenant can send. Realistic worst case is a kernel crash on a node during boot or driver reload, which on a GPU host means an unplanned outage of the whole box rather than a tenant-visible compromise.

Who can reach it

Local and indirect. No network or tenant path is described: the path needs an IPMI interface registration to fail on the host. Anyone able to load or reload the IPMI modules is already root; a flaky BMC can reach it with no attacker at all.

What to do

Take the stable kernel update that carries the fix (three stable commits linked in the record) and reboot each node. No configuration mitigation is described. Operators who do not need in-band IPMI can avoid the path entirely by not loading ipmi_msghandler/ipmi_si, but on most fleets that is what feeds hardware telemetry, so the practical answer is a kernel roll with a normal drain-and-reboot window. No vendor advisory with a fixed release number is present in the record.

References

Related entries

All Firmware, BMC & network fabric entries

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.