CVE-2026-72040 in Linux
Summary
by MITRE • 08/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical reference counting flaw within the Linux kernel's IPMI subsystem that manifests as a memory leak through improper resource management during error conditions. This issue specifically affects the ipmi driver's handling of message references when processing IPMI requests through the i_ipmi_request() function. The problem stems from an asymmetry in how reference counts are managed between successful and failed code paths, creating a permanent resource leak that can accumulate over time and potentially lead to system instability or denial of service conditions.
The technical flaw occurs at the intersection of kernel memory management and reference counting semantics within the IPMI subsystem. When a caller provides a supplied_recv message to i_ipmi_request(), the function properly increments the user's nr_msgs reference count to track the message usage. However, during error processing, the cleanup routine contains conditional logic that only frees the recv_msg buffer when the message was allocated internally by the function itself. This conditional branch fails to account for the case where a supplied_recv message is provided, leaving the reference count incremented without corresponding release operations. The error path does not execute the necessary decrement operations on nr_msgs or release the user's kref, resulting in an elevated reference count that persists beyond the intended scope of the operation.
This vulnerability creates operational impact that extends beyond simple memory consumption issues to potentially affect system stability and resource availability. The reference count leak accumulates with each failed IPMI request that uses supplied_recv messages, gradually consuming kernel memory resources while maintaining references to message structures that may no longer be needed. From an attacker perspective, this represents a potential denial of service vector where repeated error conditions can exhaust available resources, though the attack surface is limited to systems actively using IPMI functionality and experiencing error states in their IPMI request processing. The vulnerability aligns with CWE-401: Improper Release of Memory Before Removing Last Reference, which specifically addresses memory leaks caused by failure to properly manage reference counts.
The fix implemented addresses this issue through explicit resource management in the error path by ensuring that when a supplied_recv message is present with a valid user pointer, the function performs the reverse operations of those executed during successful processing. This involves explicitly decrementing the nr_msgs reference count and dropping the user's kref to maintain proper resource accounting regardless of code execution path taken. The solution follows established kernel development practices for managing reference counts in error conditions and aligns with ATT&CK technique T1499.004: Endpoint Denial of Service to address memory exhaustion vulnerabilities. The mitigation ensures that all reference counting operations are properly balanced across both successful and error execution paths, preventing resource leaks while maintaining the intended functionality of the IPMI subsystem. This fix demonstrates proper kernel memory management principles and reinforces the importance of symmetric resource handling in concurrent systems where reference counting is critical for preventing use-after-free conditions and memory corruption vulnerabilities.
The vulnerability highlights broader concerns about resource management in kernel drivers, particularly those handling complex message passing systems where multiple parties may hold references to shared resources. The issue underscores the need for careful consideration of reference counting semantics in error paths and demonstrates how seemingly minor asymmetries in code execution can lead to significant resource leaks. The fix serves as a model for similar issues in other kernel subsystems and emphasizes the critical importance of maintaining proper resource accounting even during error conditions to prevent accumulation of leaks that can degrade system performance over time.