CVE-2026-74617: dibs: initialise dibs->lock in dibs_dev_alloc()
In the Linux kernel, the following vulnerability has been resolved:
dibs: initialise dibs->lock in dibsdevalloc()
dibs->lock is initialised by dibsdevadd(), but a dibs device can already take interrupts before that call: ismprobe() runs ismdevinit(), and hence requestirq(), before it calls dibsdevadd(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ismhandleirq() takes dibs->lock unconditionally on entry, before it inspects anything else.
Initialise the lock in dibsdevalloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.
Event History
Frequently Asked Questions
What conditions are needed to trigger the issue?
The affected system must be probing an ISM device and receive a GID event interrupt after request_irq() has been called but before dibs_dev_add() initializes dibs->lock. The interrupt handler takes the lock unconditionally, so a DMB client registration is not required.
Are systems exposed by default during normal device initialization?
The exposure exists during the initialization ordering in ism_probe(): ism_dev_init() registers the interrupt handler before dibs_dev_add() initializes the lock. A GID event interrupt can occur in that interval.
What is the remediation?
Initialize dibs->lock in dibs_dev_alloc() rather than waiting for dibs_dev_add(). This ensures the lock is valid before the device can be published to its interrupt handler.