Cloudanix VulnDB

CVE-2026-99210

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in a specialized hardware driver can cause the computer to crash when the driver fails to start properly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A file-scoped rdev pointer is assigned an ERR_PTR return value from rocket_device_init() without clearing it on failure; subsequent probes treat the non-NULL pointer as valid and dereference it to read num_cores, causing an invalid memory access.

Why it matters to the business

Systems using the affected accelerator driver may experience kernel crashes or instability during device initialization, leading to downtime or reduced availability of specialized hardware acceleration.

How an attack unfolds

An attacker with local access triggers a failure path in rocket_device_init() so that rdev holds an error pointer, then forces a later probe sequence that skips reinitialization and dereferences the error value, resulting in a crash or memory corruption.

How to fix it

Apply the upstream fix that saves the error code and clears rdev on the rocket_device_init failure path; rebuild and deploy the patched kernel image.

How to confirm the fix worked

Inspect the accel/rocket driver source for the corrected probe logic that clears rdev before returning on error, or verify the running kernel contains the commit that resolves the ERR_PTR dereference.

Typical attack path

  1. Load or trigger the rocket driver probe on a system where rocket_device_init can fail
  2. Cause the init function to return an error so rdev stores an ERR_PTR
  3. Trigger a subsequent core probe that observes the non-NULL rdev and skips initialization
  4. Access rdev->num_cores through the error pointer to induce a kernel fault

How to detect it

Review kernel logs for oops or panic entries mentioning rocket_device_init, rdev, or num_cores around device probe times; correlate with module load events or accelerator device attachment.

What your security team should do

  • Prioritize kernel updates containing the rdev-clearing fix in accelerator-enabled environments
  • Monitor for kernel oops or panic reports referencing rocket_probe or num_cores
  • Restrict unprivileged module loading or device access until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: accel/rocket: clear rdev on device init failure rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path.

Affected packages

Ecosystem Package Introduced Fixed