Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:56.410Z",
  "pubdate": "2026-08-15T13:17:56.410Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel within the DIBS loopback implementation, specifically in the attach, detach, and unregister paths for dmb_node structures. The flaw arises due to a race condition where a shared memory node can be looked up under a read lock, but the lock is subsequently dropped before operating on the node's reference count. A concurrent unregister operation can drop the final reference, remove the node from the hash table, and deallocate the memory via kfree(dmb_node) before the initial thread attempts to increment the reference count.\nThis vulnerability allows a local attacker or concurrent process to trigger a use-after-free condition, potentially leading to local privilege escalation, kernel memory corruption, or a denial of service (system crash). Exploitation requires local execution context to interact with the SMC-D ISM and dibs loopback interface. The risk implication is significant as it compromises kernel memory integrity.",
  "technicalDetails": "The vulnerability resides in the Linux kernel driver handling DIBS loopback attach, detach, and unregister operations, specifically affecting dmb_node management within hash tables protected by dmb_ht_lock. The root cause is a synchronization flaw during the lifecycle management of dmb_node objects where hash table membership and reference count transitions are not executed atomically relative to each other.\nThe attack flow proceeds as follows: CPU0 executes an attach operation, acquiring read_lock_bh(&dmb_ht_lock) to look up a dmb_node where refcnt equals 1, and subsequently releases the read lock. During the unprotected window before CPU0 operates on the node's reference count, CPU1 (acting as the owner) initiates an unregister operation. CPU1 decrements the reference count via refcount_dec_and_test() transitioning it from 1 to 0, acquires write_lock_bh(&dmb_ht_lock), removes the node via hash_del(&dmb_node->list), releases the write lock, and immediately frees the memory using kfree(dmb_node). When CPU0 subsequently executes refcount_inc_not_zero(&dmb_node->refcnt), it attempts to access memory that has already been deallocated, resulting in a use-after-free condition.\nThe affected components include the functions dibs_lo_attach_dmb(), dibs_lo_detach_dmb(), dibs_lo_unregister_dmb() (renamed to dibs_lo_free_dmb()), and __dibs_lo_unregister_dmb(). The vulnerability was introduced by commit c3a910f2380f ('net/smc: implement DMB-merged operations of loopback-ism') and affected subsequent versions until addressed.\nExploitation requires local access to the system with permissions to interact with SMC-D via ISM and dibs loopback interfaces. Successful exploitation leads to kernel heap corruption, unpredictable system behavior, kernel panic, or potential code execution depending on kernel heap layout and hardening configurations."
}