Cloudanix VulnDB

CVE-2026-98926

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux graphics handling for AMD hardware could let certain power-saving actions crash the system.

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

What it actually does

Null pointer dereference in AMD display DPMS sequences due to unchecked access of optional stream->sink pointer and related link fields.

Why it matters to the business

Kernel instability or crashes on Linux systems using AMD graphics hardware, with potential for denial of service in display power management.

How an attack unfolds

An attacker with local access triggers DPMS on/off sequences where the optional sink pointer is null, causing the kernel to dereference invalid memory in the AMD display driver.

How to fix it

Update the Linux kernel to a patched version containing the DPMS sink removal, link replacement, and assert additions in the AMD display driver.

How to confirm the fix worked

Inspect kernel source for added null checks on stream->sink, replacement of sink->link with stream->link, and new asserts in USB4 bandwidth allocation and DPMS paths.

Typical attack path

  1. Obtain local user access on a Linux system with AMD GPU
  2. Induce repeated DPMS power state transitions
  3. Trigger null dereference in stream sink handling

How to detect it

Search kernel logs and dmesg for AMD display driver oops or panic messages involving null pointers or stream sink dereferences during DPMS activity.

What your security team should do

  • Apply kernel updates as soon as available due to recent publication
  • Monitor AMD display driver stability in affected environments
  • Review logs for related null pointer oops after any display power events

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Remove sink usage from DPMS [Why] stream->sink is optional and can be null, so should always be checked before dereference. Additionally, most of its usage in DPMS sequences is for stream->sink->link, which can be replaced with stream->link, as the two should always be the same. [How] * Replace stream->sink->link in DPMS on/off * Add assert to USB4 BW allocation where sink is required * Avoid inconsistencies in resource access, e.g. don't repeat stream->link after it was already saved to a local variable * Pull out effective VPG calculation to helper getter * Formatting fixes

Affected packages

Ecosystem Package Introduced Fixed