CVE-2026-74513 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister
dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb() look up the dmb_node under dmb_ht_lock, drop the lock and only then operate on the node's refcount. Nothing keeps the node alive across that window: __dibs_lo_unregister_dmb() removes the node from the hash table under the write lock and immediately frees it.
A concurrent final put can therefore free the node between the lookup and the refcount operation:
CPU0 (attach) CPU1 (owner unregisters)
read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free
The same window exists for the refcount_dec_and_test() calls in the detach and unregister paths.
Close the race structurally by making hash table membership and the refcount transitions atomic with respect to each other:
- Perform the final refcount_dec_and_test() and hash_del() in a single dmb_ht_lock write-side critical section, in both the unregister and the detach path. Freeing the node still happens after the lock is dropped, which is safe because a node whose refcount reached zero has left the hash table and can no longer be found.
- This establishes the invariant that any node found in the hash table holds at least one reference, and that the final reference can only be dropped under the write lock. dibs_lo_attach_dmb() can thus take its reference with a plain refcount_inc() while still holding the read lock; refcount_inc_not_zero() is no longer needed.
__dibs_lo_unregister_dmb() no longer touches the hash table and is renamed to dibs_lo_free_dmb() accordingly.
Note: commit cc21191b584c ("dibs: Move data path to dibs layer") moved the code to its current location; the race was introduced earlier by commit c3a910f2380f ("net/smc: implement DMB-merged operations of loopback-ism").
Tested SMC-D via ISM and dibs loopback.
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
This vulnerability resides in the Linux kernel's dibs subsystem, specifically affecting the loopback attach, detach, and unregister operations within the DMB (Data Management Block) framework. The issue manifests as a use-after-free condition that arises from a race window between hash table lookup and reference count manipulation. The vulnerability impacts the networking stack's reliability and could potentially be exploited to cause system instability or denial of service attacks.
The technical flaw emerges from improper synchronization between hash table operations and reference counting mechanisms in the dibs loopback subsystem. During normal operation, functions dibs_lo_attach_dmb(), dibs_lo_detach_dmb(), and dibs_lo_unregister_dmb() perform a lookup under read lock protection to find dmb_node entries, release the read lock, and then proceed with reference count operations. However, this design creates a window where concurrent operations can cause a node to be freed while another thread is still operating on it. The race condition occurs because __dibs_lo_unregister_dmb() removes nodes from the hash table under write lock protection before freeing them, leaving a gap where other threads could access freed memory.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable more sophisticated attacks targeting kernel memory corruption. When a node is removed from the hash table and immediately freed while another thread holds a reference to it, subsequent operations on that freed memory can corrupt kernel data structures or execute arbitrary code. This vulnerability particularly affects systems using SMC-D (Scalable Memory Communication - Data) networking features, where the dibs layer handles loopback operations for efficient data transfer between processes. The race condition is consistent across all three affected functions, making it a systemic issue that requires structural changes to address properly.
The mitigation strategy employs atomic operations to ensure that hash table membership and reference count transitions occur simultaneously under write lock protection. This approach eliminates the race window by requiring that both hash table removal and reference count decrement happen within the same critical section. The solution restructures the code so that final refcount_dec_and_test() operations and hash_del() calls are performed atomically, with node freeing occurring only after lock release but after all concurrent access has ceased. This establishes a clear invariant where any node found in the hash table maintains at least one valid reference, and the final reference can only be released under write lock protection. The implementation also removes the need for refcount_inc_not_zero() operations by allowing plain refcount_inc() calls while holding read locks, simplifying the reference counting logic.
This vulnerability aligns with CWE-416 (Use After Free) and CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization), representing a classic race condition in kernel memory management. The fix addresses the issue through structural changes rather than temporary workarounds, ensuring that the reference counting and hash table operations maintain proper synchronization. The solution follows established kernel development practices for handling concurrent access to shared data structures, similar to patterns found in various networking subsystems where atomicity between hash table operations and reference counting is essential. The change also includes renaming __dibs_lo_unregister_dmb() to dibs_lo_free_dmb() to better reflect its new role as a cleanup function rather than a registration management function, improving code clarity and maintainability.
The security implications of this vulnerability extend to potential privilege escalation scenarios where an attacker could manipulate the race condition to execute arbitrary code in kernel space. While direct exploitation may require specific conditions and system configurations, the fundamental flaw represents a serious weakness in kernel memory safety that could be leveraged in combination with other vulnerabilities. Testing has confirmed that the fix resolves the issue across both SMC-D via ISM and dibs loopback implementations, ensuring comprehensive coverage of affected networking pathways. The mitigation approach provides robust protection against similar race conditions in related subsystems while maintaining performance characteristics required for high-speed networking operations.