CVE-2026-89486: ipmi: Fix use-after-free of cmd_rcvr in _ipmi_destroy_user()
In the Linux kernel, the following vulnerability has been resolved:
ipmi: Fix use-after-free of cmdrcvr in ipmidestroyuser()
Commit 9e91f8a6c868 ("ipmi:msghandler: Remove srcu for the ipmiinterfaces list") dropped the synchronizercu() between unlinking the command receivers from intf->cmdrcvrs and freeing them, updating only the comment that explains why the barrier is needed.
The cmdrcvrs list is still traversed under plain RCU: findcmdrcvr() walks it inside rcureadlock(), and handleipmbgetmsgcmd() borrows rcvr->user from that lookup within the same read-side section. Without the grace period, ipmidestroyuser() can kfree() a cmdrcvr while a reader still holds a pointer to it, causing a use-after-free.
The rework only made srcu unnecessary for the interfaces list; the cmdrcvrs list still relies on plain RCU. Restore the synchronizercu() before freeing the receivers.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this use-after-free to occur?
A command receiver must be removed while another execution path is concurrently traversing the interface command-receiver list under an RCU read-side critical section. The race occurs because the receiver can be freed without waiting for existing RCU readers to finish.
Which kernel component is involved in the vulnerable race?
The race is in the IPMI message handler's command-receiver list, intf->cmd_rcvrs. Readers include find_cmd_rcvr() and handle_ipmb_get_msg_cmd(), while _ipmi_destroy_user() removes and frees receivers.
What change addresses the issue?
The fix restores synchronize_rcu() after command receivers are unlinked and before they are freed. This ensures readers that may still hold a receiver pointer complete before its memory is released.