CVE-2026-74513

Received Received - Intake

Use-After-Free in Linux Kernel dibs Layer

Publication date: 2026-08-15

Last updated on: 2026-08-17

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-08-15

Last Modified

2026-08-17

Generated

2026-09-04

AI Q&A

2026-08-15

EPSS Evaluated

2026-09-03

NVD

CVE-2026-74513

EUVD

EUVD-2026-59706

Affected Vendors & Products

Currently, no data is known.

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This is a use-after-free vulnerability in the Linux kernel's dibs module. It occurs when the dmb_node structure is accessed after it has been freed due to a race condition between CPU threads. The issue arises because the code looks up a node, drops the lock, then operates on the node's refcount without ensuring the node remains valid during that window.

Detection Guidance

This vulnerability is specific to the Linux kernel's dibs module and involves a use-after-free condition in loopback attach/detach/unregister operations. Detection requires kernel-level inspection for race conditions in dibs_lo_attach_dmb, dibs_lo_detach_dmb, or dibs_lo_unregister_dmb functions. No standard network or system commands directly detect this issue. Kernel logs or custom tracing tools may reveal crashes or memory corruption related to dibs operations.

Impact Analysis

This vulnerability could lead to system crashes, data corruption, or privilege escalation if exploited. Attackers could potentially trigger the use-after-free condition to execute arbitrary code or cause denial-of-service conditions on affected systems running vulnerable Linux kernel versions.

Compliance Impact

This vulnerability is a use-after-free issue in the Linux kernel's dibs module, which could lead to memory corruption or crashes. It does not directly relate to data privacy or security controls required by GDPR or HIPAA, as it is a low-level system bug rather than a data exposure or access control flaw.

Mitigation Strategies

Apply the kernel patch that fixes the race condition by making hash table membership and refcount transitions atomic. Update to a Linux kernel version containing commit cc21191b584c or later. If immediate patching is not possible, disable the dibs module or restrict usage of SMC-D via ISM and dibs loopback until patched.

Hi! I’m here to help you understand CVE-2026-74513. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70