Cloudanix VulnDB

CVE-2026-98894

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in AMD graphics error handling on Linux can make the system freeze when it encounters bad data, potentially causing unexpected downtime.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Corrupt CPER ring data can produce an entry size that fails to advance the read pointer after conversion and masking, causing the recovery loop to spin indefinitely while holding the CPER ring mutex and hanging the worker thread responsible for writing subsequent records.

Why it matters to the business

Linux systems using AMD GPUs may experience sudden freezes or hangs under certain hardware error conditions, leading to unplanned downtime and requiring manual intervention or reboot.

How an attack unfolds

An attacker or environmental fault introduces malformed CPER entries into the ring buffer; during overflow recovery the kernel trusts the bogus size field, enters a no-progress loop, and blocks further CPER processing, resulting in denial of service.

How to fix it

Apply the upstream kernel patch that detects a no-progress rptr update and resets the CPER ring to an empty state; rebuild and deploy the updated kernel on affected AMD platforms.

How to confirm the fix worked

Confirm the presence of the reset-on-no-progress logic in the drm/amd/ras CPER handling code and verify that the ring mutex is released promptly even when corrupt entries are present.

Typical attack path

  1. Trigger or simulate CPER ring overflow conditions
  2. Supply a corrupt entry whose parsed size does not advance rptr after dword conversion and masking
  3. Allow the recovery loop to acquire the CPER ring mutex and enter the spin
  4. Observe worker thread hang and blocked CPER record writes

How to detect it

Inspect kernel logs for repeated CPER ring recovery messages without progress, worker thread stack traces showing mutex acquisition in ras_cper, and any watchdog reports of hung tasks related to AMD RAS.

What your security team should do

  • Prioritize kernel updates on AMD GPU systems within the next maintenance window
  • Monitor dmesg and worker thread traces for CPER ring mutex contention
  • Test the fix in a lab environment that can inject corrupt CPER data

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: reset CPER ring on corrupt entry size When CPER ring overflow handling advances the read pointer, it trusts the parsed entry size from the current ring contents. Corrupt CPER data can produce an entry size that does not advance rptr after dword conversion and pointer masking. In that case the recovery loop keeps testing the same location while holding the CPER ring mutex. This can hang the worker that is writing the next CPER record. Detect a no-progress rptr update and reset the CPER ring to an empty state instead. This drops the corrupt contents and lets the writer leave the recovery path without spinning.

Affected packages

Ecosystem Package Introduced Fixed