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.
Published: 2026-08-15
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw originates from a race condition in the DMB loopback code where a node can be freed after its reference count is decremented but before the lookup lock is released. This permits a concurrent thread to access a freed object, resulting in a use‑after‑free situation. The vulnerability is a classic Use‑after‑free weakness and could allow an attacker to corrupt kernel memory, potentially leading to code execution or privilege escalation on a system with local access.

Affected Systems

All Linux kernel installations that include the DMB loopback handling code before the commit cc21191b584c were potentially affected. The CPE information lists only the generic Linux kernel, and version data is not supplied; it is inferred that any kernel version containing the code in the described state is vulnerable.

Risk and Exploitability

The EPSS score is < 1% and the vulnerability is not listed in the CISA KEV catalog, indicating no known public exploits at this time. However, for systems running older kernel code, the risk is significant because the flaw resides in the kernel and requires a local attacker with the ability to trigger concurrent attach, detach, or unregister operations. The explicit mention of a use‑after‑free and the required race conditions suggest that exploitation would be local and privileged, with the potential for arbitrary code execution in kernel mode if successfully triggered.

Generated by OpenCVE AI on August 21, 2026 at 22:51 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that incorporates the fix provided in commit cc21191b584c and any related patches
  • If immediate kernel upgrade is not possible, disable or restrict the DMB loopback features to prevent concurrent attach/detach/unregister operations that could trigger the race
  • Limit local privileged access to the system, ensuring that only trusted users can exercise code paths that interact with the DMB loopback code

Generated by OpenCVE AI on August 21, 2026 at 22:51 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 21 Aug 2026 21:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Thu, 20 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 17 Aug 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Mon, 17 Aug 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 15 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 12:45:00 +0000

Type Values Removed Values Added
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.
Title dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:48:04.292Z

Reserved: 2026-08-15T05:44:03.909Z

Link: CVE-2026-74513

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T13:17:56.410

Modified: 2026-08-17T06:19:48.007

Link: CVE-2026-74513

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74513 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-21T23:00:14Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference