CVE-2026-98938: rust: irq: pass RegistrationInner as cookie to request_irq
In the Linux kernel, the following vulnerability has been resolved:
rust: irq: pass RegistrationInner as cookie to requestirq
With commit ba268514ea14 ("rust: devres: fix race condition due to nesting"), Devres::new() returns Result<Self> by value instead of initializing in-place via PinInit. Because requestirq() is called inside Devres::new(), registration.inner is still uninitialized when the IRQ is enabled, so accessing registration.inner.device() in the IRQ callback can read uninitialized memory.
Fix this by storing the Device and handler pointer in RegistrationInner and passing RegistrationInner as the IRQ cookie after its fields are initialized.
This is not needed in mainline because commit 98c63ce4d760 ("rust: irq: make Registration compatible with lifetime-bound drivers") removed Devres from irq::Registration and moved requestirq() after all fields are initialized.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Rust IRQ registration implementation, store the Device and handler pointer in RegistrationInner, initialize RegistrationInner in-place via PinInit, and call request_irq() only after all fields are initialized; pass RegistrationInner as the IRQ cookie.
Event History
Frequently Asked Questions
Which kernel configurations are exposed to this issue?
The issue applies to kernel code that combines the Devres::new() behavior introduced by commit ba268514ea14 with the Rust IRQ registration implementation described here. Mainline is stated not to need this fix because commit 98c63ce4d760 removed Devres from irq::Registration and ensures request_irq() runs after initialization.
What must occur for the uninitialized-memory access to happen?
An IRQ must be enabled while Devres::new() is still executing, before registration.inner has been initialized. If the IRQ callback runs in that interval and accesses registration.inner.device(), it can read uninitialized memory.
What change mitigates the problem when updating the kernel is not immediately possible?
The described fix initializes the Device and handler pointer in RegistrationInner, then passes RegistrationInner as the IRQ cookie only after those fields are initialized. This prevents the callback from dereferencing an uninitialized registration.inner.