UBUNTU-CVE-2026-74513: Use After Free
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
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What level of access does an attacker need to exploit this issue?
The vulnerability is locally exploitable and requires low privileges. No user interaction is required.
Which Ubuntu kernel packages are listed as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-hwe-edge, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, and ubuntu/linux-aws-5.0.
What could a successful exploit allow?
The severity vector rates confidentiality, integrity, and availability impact as high. This indicates a successful exploit could have significant effects on all three.