Executive brief
The Linux kernel's dibs (data path) driver initializes a critical synchronization lock too late in the device startup sequence, leaving a narrow window where interrupt handlers can execute and attempt to access the uninitialized lock. This could cause kernel panics or instability if a GID event interrupt occurs during device probe before the lock is ready, affecting systems using ISM (IBM Shared Memory) network devices.
Technical details
This is a race condition in lock initialization affecting the dibs kernel subsystem. The dibs->lock spinlock was initialized in dibs_dev_add(), but interrupt handlers (specifically ism_handle_irq()) attempt to acquire this lock immediately upon device initialization in dibs_dev_alloc(). When ism_probe() calls request_irq() before dibs_dev_add(), a GID event interrupt can fire and cause the handler to access an uninitialized lock, triggering undefined behavior. The fix moves spin_lock_init(&dibs->lock) from dibs_dev_add() to dibs_dev_alloc() to ensure the lock is valid before interrupts are enabled. No special privileges or network access are required; the vulnerability is triggered by normal device probe sequences on affected hardware.
Affected products
- Linux Linux kernel affected versions prior to fix commit c27e360545373b7aee9862a5beef3b9fb3df0c25
Timeline
- 2026-08-22: disclosed: CVE-2026-74617 published
- 2026-08-05: patched: Upstream fix commit c27e360545373b7aee9862a5beef3b9fb3df0c25