Cloudanix VulnDB

CVE-2026-98270

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in certain AMD graphics drivers for Linux could make computers crash during startup if an interrupt happens at exactly the wrong moment.

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

What it actually does

Null pointer dereference in nbio_v7_9_handle_ras_controller_intr_no_bifring() when amdgpu_ras_get_context() or amdgpu_ras_find_obj() return NULL during the early RAS initialization window before the PCIE_BIF object is created, resulting in a crash in hard-IRQ context.

Why it matters to the business

Unexpected system crashes or instability on Linux systems using affected AMD GPUs, causing operational downtime and potential data loss during boot or driver initialization; low immediate risk given no known exploitation.

How an attack unfolds

An attacker with local access or the ability to influence hardware interrupts attempts to trigger the fatal-error interrupt during the narrow initialization window after adev->nbio.ras is set but before the RAS object exists, causing the handler to dereference NULL pointers and panic the kernel.

How to fix it

Apply the upstream fix (commit c7071767a50a32ed727cf800ac84372429e3b4b3 or equivalent cherry-pick) that adds NULL checks for ras and obj before dereference in the nbio_v7_9 handler; update to a patched Linux kernel release containing this change.

How to confirm the fix worked

Inspect the amdgpu driver source for the presence of NULL checks on ras and obj in nbio_v7_9_handle_ras_controller_intr_no_bifring(); confirm no kernel panics referencing this function occur during RAS initialization on test systems.

Typical attack path

  1. Gain local access or control over interrupt timing on a vulnerable AMDGPU system
  2. Force or wait for the driver initialization sequence to enter the RAS setup window
  3. Trigger the relevant RAS controller interrupt before late_init completes
  4. Crash the kernel in hard-IRQ context via NULL dereference

How to detect it

Search kernel logs, dmesg, and crash dumps for stack traces containing nbio_v7_9_handle_ras_controller_intr_no_bifring, amdgpu_ras_get_context, or amdgpu_ras_find_obj during early driver init; correlate with boot-time hardware interrupt events.

What your security team should do

  • Prioritize kernel updates on all AMDGPU-equipped Linux hosts within standard patching cycles
  • Monitor kernel logs for oops/panics mentioning amdgpu RAS or nbio_v7_9 during boot
  • Review EPSS and KEV status weekly for any increase in exploit maturity

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check ras and obj before dereference nbio_v7_9_handle_ras_controller_intr_no_bifring() dereferences ras and obj without checking either for NULL. Both amdgpu_ras_get_context() and amdgpu_ras_find_obj() can return NULL, e.g. during the window between adev->nbio.ras being set (early in amdgpu_ras_init(), by design, to enable the fatal-error interrupt as soon as possible) and the PCIE_BIF ras object actually being created in RAS late_init. Any interrupt in that window crashes in hard-IRQ context. This is analogous to commit d190b459b2a4 ("drm/amdgpu: the warning dereferencing obj for nbio_v7_4"), which fixed the same issue in the nbio_v7_4 handler. Found by Linux Verification Center (linuxtesting.org) with SVACE. (cherry picked from commit c7071767a50a32ed727cf800ac84372429e3b4b3)

Affected packages

Ecosystem Package Introduced Fixed