CVE-2026-98938
NoneCVSS
—
EPSS
0.2%
Published
Oct 23, 2026
CISA due date
—
Cloudanix analysis
A recent change in the Linux kernel's Rust support for handling device interrupts left a small window where the kernel could read leftover memory, which might cause crashes or leaks on machines using certain modern drivers.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw causes an IRQ callback to read uninitialized memory because request_irq is invoked inside Devres::new() before RegistrationInner fields (Device and handler pointer) are written, leaving registration.inner.device() pointing to garbage when the interrupt fires.
Why it matters to the business
Linux systems that load Rust-based device drivers may suffer sporadic kernel crashes, undefined behavior, or leakage of kernel memory contents, leading to service outages and potential data exposure on affected machines.
How an attack unfolds
An attacker with the ability to trigger device interrupts during the narrow initialization window of a Rust IRQ Registration object can cause the handler to dereference uninitialized pointers, resulting in memory corruption or information disclosure.
How to fix it
Upgrade to a Linux kernel that includes the fix storing Device and handler inside RegistrationInner and passing RegistrationInner itself as the IRQ cookie after all fields are initialized; rebuild and redeploy any out-of-tree Rust drivers that depend on the corrected API.
How to confirm the fix worked
Inspect kernel source or running vmlinux for the presence of the commit that moves request_irq after RegistrationInner initialization and confirms the cookie is no longer an uninitialized inner pointer; test IRQ registration paths under concurrent interrupt load.
Typical attack path
- Load or trigger a Rust driver that uses irq::Registration wrapped in Devres
- Time or induce an interrupt while request_irq has enabled the line but before RegistrationInner is fully written
- Execute the callback that calls device() on the uninitialized inner structure
- Read or corrupt kernel memory via the resulting dereference
How to detect it
Search kernel logs and dmesg for oops or panic messages referencing uninitialized memory in IRQ paths or Rust devres/irq modules; correlate with driver load times and unexpected interrupt storms.
What your security team should do
- Apply the corrected kernel version to all systems that compile or load Rust drivers within the next patch cycle
- Audit custom Rust kernel modules for use of the pre-fix irq::Registration + Devres pattern
- Monitor EPSS and exploit maturity; re-evaluate if new public PoCs appear
The record
In the Linux kernel, the following vulnerability has been resolved: rust: irq: pass RegistrationInner as cookie to request_irq 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 request_irq() 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 request_irq() after all fields are initialized.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|