CVE-2026-74617 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
dibs: initialise dibs->lock in dibs_dev_alloc()
dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else.
Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The identified vulnerability resides within the Linux kernel's Device Interface for Broadband Services (dibs) subsystem, specifically affecting the initialization sequence of synchronization primitives used in interrupt handling routines. The core technical flaw stems from an incorrect ordering of operations during the driver probe and device allocation phases. Specifically, the mutex lock member dibs->lock was previously initialized only within the dibs_dev_add function. However, the operational lifecycle of a dibs device involves earlier steps where hardware interrupts can be registered and potentially triggered before this initialization occurs. The ism_probe function invokes ism_dev_init, which in turn calls request_irq to register an interrupt handler for the device. This registration happens prior to the invocation of dibs_dev_add, creating a window of time during which the device object exists but its associated lock remains uninitialized or contains garbage data.
This timing discrepancy creates a race condition that can lead to undefined behavior when interrupts are processed. Although it is true that no client has registered a Device Management Block (DMB) at this early stage—meaning DMB-specific interrupts cannot occur—the system still supports Global Identifier (GID) event interrupts. The interrupt handler function, ism_handle_irq, unconditionally acquires dibs->lock upon entry to protect critical sections of code. Because the lock has not yet been initialized by that point in execution flow, any attempt to acquire this uninitialized mutex results in a kernel panic or memory corruption due to accessing invalid memory structures associated with an improperly constructed synchronization object. This represents a classic case of improper initialization leading to potential denial of service through system crash under specific hardware interrupt conditions.
From a vulnerability classification perspective, this issue aligns with CWE-665, which describes Improper Initialization, as the resource (the mutex lock) is not properly set up before being used. Furthermore, it relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, because the lack of a valid lock allows concurrent access or interrupt handling without proper mutual exclusion guarantees once the handler begins execution. In terms of the MITRE ATT&CK framework for enterprise security, this type of flaw can be leveraged in techniques related to privilege escalation if an attacker can trigger specific hardware states that force early interrupt processing before driver initialization completes, although primarily it serves as a stability and availability risk rather than a direct exploitation vector for code execution.
The remediation strategy implemented addresses the root cause by moving the initialization of dibs->lock from dibs_dev_add to dibs_dev_alloc. This change ensures that the synchronization primitive is valid immediately after the device structure is allocated, which precedes any point where interrupts might be requested or handled. By establishing this invariant early in the object's lifecycle, the driver guarantees thread safety and interrupt handler stability regardless of when request_irq is called relative to other setup functions. To mitigate similar issues in kernel development, it is recommended that developers strictly adhere to a pattern where all synchronization primitives are initialized during allocation rather than deferred until later configuration steps. Additionally, static analysis tools should be configured to detect uses of uninitialized mutexes or spinlocks within interrupt contexts to prevent such race conditions from reaching production kernels.