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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
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.