CVE-2026-74617

Unknown

Last modified

CVE-2026-74617 is a vulnerability of currently unknown severity. 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..

Description

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.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= cc21191b584c6f7836b0f10774f8278b7cbfba10, < fe79571f40434b257d68cbfb7b3ae93a794d8a11; >= cc21191b584c6f7836b0f10774f8278b7cbfba10, < 2926031acba100d0c18fcfaa7a2ed29609318848; >= cc21191b584c6f7836b0f10774f8278b7cbfba10, < c27e360545373b7aee9862a5beef3b9fb3df0c25
LinuxLinux6.18

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-74617?
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.
How severe is CVE-2026-74617?
Severity scoring for CVE-2026-74617 is pending analysis.
How do I fix CVE-2026-74617?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-74617?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST