Cloudanix VulnDB

CVE-2026-98938

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Load or trigger a Rust driver that uses irq::Registration wrapped in Devres
  2. Time or induce an interrupt while request_irq has enabled the line but before RegistrationInner is fully written
  3. Execute the callback that calls device() on the uninitialized inner structure
  4. 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