CVE-2026-72040None▾ SunlitIn the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` referenc…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Aug 23.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.2%
0.2% → 0.2%
In the Linux kernel, the following vulnerability has been resolved:
ipmi: fix refcount leak in i_ipmi_request()
When a caller provides a supplied_recv message to i_ipmi_request(),
the function increments the user's nr_msgs reference count. If an
error occurs later, the out_err cleanup path only frees the recv_msg
if the function allocated it itself (i.e., !supplied_recv). In the
supplied_recv case the cleanup is skipped, leaving the reference count
elevated. The caller ipmi_request_supply_msgs() does not release the
supplied_recv on error, so the reference is permanently leaked.
Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.