EUVD-2026-64554
GHSA-65j5-6jf7-5p7m
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Local s390 device-probe race, not network-reachable; high-complexity timing window and privileged/hardware context give AC:H/PR:H; impact is kernel instability (A:H) with no confidentiality or integrity disclosure.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Improper initialization ordering in the Linux kernel's dibs (Direct Internal Buffer Sharing) subsystem leaves dibs->lock uninitialized during early ISM device probe, so a GID-event interrupt arriving between ism_dev_init()/request_irq() and dibs_dev_add() causes ism_handle_irq() to acquire an uninitialized spinlock. This affects s390 systems using ISM/SMC-D devices and can lead to undefined locking behavior and kernel instability. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires an s390/IBM Z system with an ISM (Internal Shared Memory) device driving the dibs subsystem; the trigger is a GID-event interrupt arriving after request_irq() in ism_dev_init() but before dibs_dev_add() initializes dibs->lock. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided signals conflict sharply and must be reconciled. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | On an IBM Z system, during ISM device initialization the driver registers its interrupt handler before dibs_dev_add() runs; a GID event interrupt fires in that narrow window and ism_handle_irq() acquires the still-uninitialized dibs->lock, producing undefined locking behavior that can destabilize or crash the kernel. This is a timing/hardware-driven race rather than an attacker-crafted input path, and no public exploit code exists. … |
| Remediation | Vendor-released patch: update to a fixed stable kernel - 6.18.45, 7.1.9, or 7.2 (or later), which move spin_lock_init to dibs_dev_alloc(). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Immediate (24 hours): Identify and inventory all s390 systems running Linux kernel with ISM/SMC-D devices; contact your Linux distribution provider to confirm patch availability and obtain the patched kernel version. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today