Linux kernel ipmi: use-after-free of cmd_rcvr when an IPMI user is destroyed

UnscoredCVE-2026-89486Firmware, BMC & network fabriccurated

Impact

A refactor that removed SRCU from the ipmi_interfaces list also dropped the synchronize_rcu() between unlinking command receivers from intf->cmd_rcvrs and freeing them, leaving only the explanatory comment behind. The cmd_rcvrs list is still walked under plain RCU - find_cmd_rcvr() runs inside rcu_read_lock() and handle_ipmb_get_msg_cmd() borrows rcvr->user from that lookup in the same read-side section - so _ipmi_destroy_user() can kfree() a receiver while a reader still holds a pointer to it. On a datacenter server the IPMI stack is always present and talks to the BMC, so this is a host-kernel use-after-free reachable on the path between the OS and out-of-band management: at minimum a node crash, and a use-after-free in kernel context is a privilege-escalation candidate. It needs a local IPMI user to be closing while IPMB traffic is being dispatched.

Who can reach it

Local user able to open /dev/ipmi* (typically root or a management group; ipmitool, ipmi_si consumers, monitoring agents). Requires racing a user close against inbound IPMB message dispatch. No path from the network to this without first having local access to the IPMI device.

What to do

Update the host kernel to a stable release that restores the synchronize_rcu() (three stable commits linked) and reboot the node. As an interim control, restrict /dev/ipmi* to the management agents that genuinely need it, since local access to the device is the precondition. No fixed release number is stated in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89486 https://git.kernel.org/stable/c/05ec76cfbce653e07cec19b9b8b20e33449d5d87 https://git.kernel.org/stable/c/5dc0b2a9af95a97861c1bffaf1687a3173e395c5

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.