CVE-2026-99151 in Linux
Summary
by MITRE • 10/28/2026
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)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel's display manager subsystem, specifically the AMD Display driver for USB4 bandwidth allocation functions, contained a critical flaw involving improper handling of null pointers. The vulnerability resided in two primary functions: allocate_usb4_bandwidth_for_stream and allocate_usb4_bandwidth. These routines are responsible for managing resource allocation for display streams over USB4 interfaces. The core issue stemmed from the use of ASSERT macros to validate that stream->sink was not NULL before dereferencing it to access link information. While assertions serve as valuable diagnostic tools during development, they are typically compiled out in production kernel builds to optimize performance and reduce overhead. Consequently, when a null sink pointer occurred in a deployed environment, the protective check vanished, leaving the code vulnerable to immediate memory corruption upon execution of the subsequent dereference operation.
This flaw represents a classic instance where developer intent for safety during testing was not translated into robust runtime error handling. The context confirms that stream->sink can legitimately be NULL under certain operational conditions, as evidenced by existing guards in link_set_dpms_off which explicitly check for nullity before accessing sink members. However, the deallocation path within link_set_dpms_off lacked this same level of defensive programming. When the system attempted to deallocate USB4 bandwidth resources without verifying the existence of the sink object, it triggered a NULL pointer dereference. In kernel space, such an error results in a page fault that cannot be recovered from gracefully, leading directly to a kernel panic and subsequent system crash or reboot. This constitutes a denial-of-service condition for any user relying on stable display functionality over USB4 connections.
From a vulnerability classification perspective, this defect aligns with CWE-476: NULL Pointer Dereference. The failure lies in the assumption that input data structures will always be valid without rigorous runtime validation. In terms of attack vectors and behavioral patterns, while this is primarily an internal stability issue rather than a direct remote exploit vector, it can be triggered by specific hardware configurations or driver state transitions where display streams are torn down unexpectedly. This behavior maps to ATT&CK technique T1499: Endpoint Denial of Service, as the exploitation results in the unavailability of the computing platform due to system instability. The impact is severe for enterprise environments relying on continuous uptime and stable peripheral connectivity via USB4 docks or displays.
The remediation strategy implemented involves replacing the non-functional ASSERT calls with explicit conditional checks that verify stream->sink before any dereference occurs. If the sink pointer is found to be NULL, the functions now return false early, preventing execution of unsafe memory operations. This approach ensures graceful degradation rather than catastrophic failure. Furthermore, consistency was applied across the codebase by adding a matching null check at the deallocation call site within link_set_dpms_off. Retaining ASSERT calls for diagnostic purposes allows developers to detect unexpected states during debugging phases without compromising production stability. This patch exemplifies best practices in kernel development where defensive programming is prioritized over assumption-based logic, ensuring resilience against edge cases involving hardware state changes or driver lifecycle events.