CVE-2026-74629 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net/dibs: Correct freeing of dmb_clientid_arr
A dibs device interrupt handler can be active after dibs_dev_del() and may still access dmb_clientid_arr. (UAF)
In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe() dmb_clientid_arr is freed twice (double free).
Free dmb_clientid_arr in dibs_dev_release() after last reference is gone. Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok for now, because no dmbs can be registered before dibs_dev_add().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The Linux kernel vulnerability identified within the net/dibs subsystem involves critical memory management errors related to the dmb_clientid_arr structure. This component is central to the operation of the DIBS device driver, which handles network communication protocols requiring robust state management for client identification and resource allocation. The core issue stems from improper lifecycle management of this array, leading to two distinct but severe classes of vulnerabilities: use-after-free conditions resulting from race conditions during device removal, and double free errors triggered by initialization failures. These flaws compromise the integrity of kernel memory structures and can lead to system instability or potential privilege escalation if exploited by a local attacker with access to the relevant hardware interfaces.
The first critical flaw involves a use-after-free scenario where the dibs device interrupt handler remains active after the dibs_dev_del function has been invoked. When a device is logically removed from the kernel's internal structures, it is expected that all associated resources are safely deallocated and no further access occurs. However, in this implementation, there exists a race condition wherein an interrupt triggered by hardware activity can execute code paths that attempt to read or write to dmb_clientid_arr after its memory has already been released. This situation arises because the cleanup sequence does not adequately synchronize with pending asynchronous operations such as interrupts. An attacker who can trigger device removal while simultaneously causing interrupt events could exploit this window of vulnerability to access freed memory, potentially reading sensitive kernel data or corrupting heap structures by writing arbitrary values into previously allocated regions that may have been reallocated for other purposes.
The second major issue is a double free error occurring during the initialization phase when dibs_dev_add fails after being called from dibs_lo_dev_probe. In this specific code path, if an allocation or setup step within dibs_dev_add encounters an error and returns failure, the cleanup routine incorrectly attempts to deallocate dmb_clientid_arr more than once. The first free occurs during the initial partial initialization, and a second free is triggered by the error handling logic that assumes full ownership of the resource without verifying whether it was already released or never fully allocated in subsequent steps. Double frees are particularly dangerous as they can corrupt the kernel's memory allocator metadata structures, such as slab caches or buddy system descriptors. This corruption often leads to immediate kernel panics and system crashes, denying service to all users on the affected machine. In more sophisticated exploitation scenarios, careful manipulation of heap state via double free vulnerabilities can allow an attacker to achieve arbitrary code execution by controlling how freed chunks are merged or split during subsequent allocations.
From a standards perspective, these issues map directly to CWE-416 Use After Free and CWE-415 Double Free, which represent fundamental memory safety violations in C-based systems like the Linux kernel. The race condition aspect of the use-after-free vulnerability also aligns with CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization. Furthermore, from a tactical standpoint within the MITRE ATT&CK framework for enterprise security, these vulnerabilities facilitate initial access and privilege escalation techniques. Specifically, they support T1059 Command Scripting or T1068 Exploitation for Privilege Escalation by allowing an unprivileged user to crash the system (Denial of Service via CWE-400) or potentially gain higher privileges through heap corruption exploitation. The lack of proper synchronization between device lifecycle events and interrupt handling represents a classic concurrency bug that undermines the reliability of kernel subsystems.
To mitigate these vulnerabilities, developers must ensure strict adherence to reference counting principles for all dynamically allocated resources within driver code. Specifically, dmb_clientid_arr should be freed exclusively in dibs_dev_release(), which is guaranteed to execute only after the last user reference to the device structure has been dropped and no further interrupts can occur. This approach decouples resource deallocation from immediate error handling paths that might race with hardware events. Additionally, proper synchronization mechanisms such as mutexes or atomic operations should be employed around any access to shared state during device removal to prevent interrupt handlers from accessing memory after it has been marked for deletion but before it is physically reclaimed by the allocator. For initialization failures in dibs_dev_add, error handling paths must carefully track which resources have already been allocated and freed to avoid redundant deallocation calls. Regular static analysis using tools like KASAN (Kernel Address Sanitizer) can help detect these memory errors during development, ensuring that race conditions and double frees are identified before deployment.