Cloudanix VulnDB

CVE-2026-99151

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux graphics drivers for certain AMD hardware can crash the whole computer when handling USB4 connections because a safety check only works during testing and not on real systems.

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 allocate_usb4_bandwidth_for_stream(), allocate_usb4_bandwidth(), and deallocate_usb4_bandwidth() because ASSERT(stream->sink) is stripped in production builds, allowing dereference of stream->sink->link when sink is legitimately NULL.

Why it matters to the business

Kernel panic or system instability on AMD GPUs using USB4 display paths, leading to unexpected reboots, display failures, and potential data loss or service disruption on affected Linux systems.

How an attack unfolds

An attacker with local access or the ability to manipulate display/USB4 stream configurations triggers the bandwidth allocation or deallocation paths with a NULL sink pointer; the missing runtime checks cause an immediate kernel NULL dereference and crash.

How to fix it

Apply the upstream fix that replaces ASSERT calls with explicit NULL checks returning false early and adds a matching guard in link_set_dpms_off() before the deallocate call; rebuild and deploy the patched kernel.

How to confirm the fix worked

Confirm the patched kernel source contains explicit if (!stream->sink) return false; guards around the sink dereferences in the USB4 bandwidth functions and verify the change via git log or code review.

Typical attack path

  1. Obtain local execution or driver interaction capability on target system
  2. Create or manipulate a display stream that leaves stream->sink as NULL
  3. Invoke USB4 bandwidth allocation or DPMS-off paths that dereference the sink without a guard
  4. Trigger kernel panic via NULL pointer access

How to detect it

Inspect kernel logs and crash dumps for NULL pointer dereference oops originating from drm/amd/display USB4 bandwidth functions; correlate with recent display or USB4 stream activity.

  • NULL pointer dereference in allocate_usb4_bandwidth
  • NULL pointer dereference in allocate_usb4_bandwidth_for_stream
  • drm/amd/display USB4 bandwidth NULL sink

What your security team should do

  • Prioritize kernel update for systems with AMD display hardware using USB4
  • Monitor kernel oops and panic logs for NULL dereference signatures in drm/amd/display
  • Test patched kernels in staging environments before broad deployment
  • Restrict unprivileged access to display and USB4 configuration interfaces where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT is compiled out in production builds, so a NULL stream->sink causes a NULL pointer dereference. link_set_dpms_off() already guards two earlier accesses to stream->sink with explicit NULL checks, confirming that stream->sink can legitimately be NULL. The subsequent call to deallocate_usb4_bandwidth() had no equivalent guard. Replace the ASSERT() calls with proper NULL checks that return false early, and add a matching stream->sink guard at the call site in link_set_dpms_off() consistent with the surrounding pattern. v2: Keep the existing ASSERT() calls for diagnostics (to report unexpected NULL sink), and add explicit NULL checks that return false before dereferencing stream->sink. Also add a matching stream->sink guard at the deallocation call site in link_set_dpms_off(). (Alex) (cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355)

Affected packages

Ecosystem Package Introduced Fixed