GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel IPMI: refcount leak on the supplied-recv error path permanently pins the IPMI user

CVE-2026-72040Firmware, BMC & network fabriccurated

Impact

When a caller passes its own recv message to i_ipmi_request(), the function bumps the user's nr_msgs and takes a kref, but the out_err path only cleans up messages the function allocated itself. In the supplied-recv case the counts are never reverted and ipmi_request_supply_msgs() does not release it either, so every failed request permanently consumes one slot against that user's in-flight message limit and holds a reference on the IPMI user object. A process that loops on requests failing after that point can wedge its own IPMI channel until reboot, which matters on a GPU node because host-side IPMI is how fleet tooling reads inlet temperature, PSU and DIMM health and talks to the BMC - the telemetry you would use to decide whether to pull the node. This is a resource leak; the record shows no memory corruption or privilege escalation.

Who can reach it

Local only, and effectively privileged: a process able to open /dev/ipmi* - root on a standard install, or a monitoring container that has the device mapped in - issuing requests that fail after the reference is taken. Not reachable over the network and not reachable by an ordinary tenant pod without that device.

What to do

Take a stable kernel containing the fix (commits linked in the record) and reboot. The elevated counts and leaked krefs cannot be reclaimed at runtime, so an already-affected node needs a reboot either way; treat it as a routine drain-and-reboot rather than an emergency window. No vendor fixed-version numbers appear in the record beyond the stable commits.

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.