CVE-2026-72082 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()
When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object.
Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery.
Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/16/2026
The Linux kernel vulnerability identified within the SCSI Elastic Fabric Target driver involves a reference counting leak and state management error in the efct_hw_io_abort function. This issue arises specifically when the internal request tag allocation routine, efct_hw_reqtag_alloc, fails to allocate resources due to space constraints or other system limitations. In this specific failure scenario, the code path returns an -ENOSPC error code without executing the necessary cleanup procedures that are present in all other error handling branches of the function. The primary technical flaw is the omission of a kref_put call for the io_to_abort object, which had previously been incremented via kref_get_unless_zero at the beginning of the operation. This oversight results in a permanent reference leak where the kernel retains ownership of the I/O structure indefinitely because its reference count never reaches zero to trigger deallocation.
From an operational perspective, this vulnerability leads to two distinct negative outcomes that degrade system stability and performance. First, the accumulation of unreleased references consumes kernel memory resources over time, potentially contributing to resource exhaustion in long-running systems or those with high I/O abort rates. Second, and more critically, the function leaves the abort_in_progress flag set to true even though the abort operation was never successfully submitted due to the allocation failure. This state inconsistency creates a logical deadlock scenario where subsequent attempts to abort the same I/O command will immediately fail with an -EINPROGRESS error code. Because the system believes an abort is already underway, it prevents any further recovery actions or retries for that specific I/O request, effectively blocking storage operations and potentially causing application-level timeouts or data integrity issues depending on how higher layers handle these persistent failures.
This vulnerability aligns with CWE-401, which describes a missing release of memory after successful allocation, as well as CWE-362 regarding concurrent execution race conditions that can arise from improper state management in asynchronous operations. The behavior also relates to ATT&CK technique T1529, specifically the system shutdown or reboot avoidance aspect if the resulting resource exhaustion prevents normal operational continuity, although this is a secondary effect of the primary memory leak and logic error. The root cause lies in inconsistent error handling paths within the driver code where one branch fails to mirror the cleanup logic present in others, such as the efct_hw_wq_write failure path which correctly handles both reference counting and state reset.
To mitigate this vulnerability, the kernel developers have implemented a fix that introduces the missing kref_put call immediately after detecting the allocation failure, ensuring that the reference count is properly decremented to allow for eventual object release when no other references exist. Additionally, the abort_in_progress flag is explicitly reset to false in this error path, restoring consistent state management and allowing future operations on the I/O command to proceed normally rather than being blocked by a phantom ongoing abort status. System administrators should ensure that their Linux kernels are updated with patches addressing this specific efct driver issue, particularly for environments relying heavily on Elastic Fabric Adapter hardware where high-frequency I/O aborts might trigger this condition more frequently. Regular monitoring of kernel memory usage and storage subsystem logs can help detect early signs of reference leaks or persistent abort failures before they lead to significant service disruption.