CVE-2026-74513: dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister
In the Linux kernel, the following vulnerability has been resolved:
dibs: fix use-after-free of dmbnode in loopback attach/detach/unregister
dibsloattachdmb(), dibslodetachdmb() and dibslounregisterdmb() look up the dmbnode under dmbhtlock, drop the lock and only then operate on the node's refcount. Nothing keeps the node alive across that window: dibslounregisterdmb() 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)
readlockbh(&dmbhtlock) find dmbnode (refcnt == 1) readunlockbh(&dmbhtlock) refcountdecandtest() 1 -> 0 writelockbh(&dmbhtlock) hashdel(&dmbnode->list) writeunlockbh(&dmbhtlock) kfree(dmbnode) refcountincnotzero(&dmbnode->refcnt) <-- use-after-free
The same window exists for the refcountdecandtest() 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 refcountdecandtest() and hashdel() in a single dmbhtlock 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. dibsloattachdmb() can thus take its reference with a plain refcountinc() while still holding the read lock; refcountincnotzero() is no longer needed.
dibslounregisterdmb() no longer touches the hash table and is renamed to dibslofreedmb() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch cc21191b584c - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch c3a910f2380f - Configuration
Close the race by ensuring __dibs_lo_unregister_dmb() no longer touches the hash table outside the dmb_ht_lock write-side critical section: look up the dmb_node under dmb_ht_lock, drop the lock and only then operate on the node's refcount; then, under the dmb_ht_lock write lock, perform the final refcount_dec_and_test() and hash_del() together and free the node only after removal.
Linux kernel dibs DMB loopback attach/detach/unregister dmb_ht_lock and refcount/hash membership ordering = Do hash table membership/removal and final freeing after obtaining the write lock; perform final refcount_dec_and_test() and hash_del() as a single operation under the write lock
Event History
Frequently Asked Questions
What is the severity of CVE-2026-74513?
The severity of CVE-2026-74513 is rated at 44, indicating a significant risk level.
What type of vulnerability is CVE-2026-74513?
CVE-2026-74513 is classified as a use-after-free vulnerability in the Linux kernel.
How do I fix CVE-2026-74513?
To fix CVE-2026-74513, update to the latest version of the Linux kernel that includes the patch for this vulnerability.
Which components are affected by CVE-2026-74513?
CVE-2026-74513 affects functions related to dmb_node in the Linux kernel's loopback attachment and detachment processes.
Can CVE-2026-74513 be exploited remotely?
There is a potential for CVE-2026-74513 to be exploited remotely due to its nature involving loopback operations.