CVE-2026-99151: Linux kernel · drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions
Affects Linux kernelSource GCVE Database
Not known to be exploited.
Data as of 29 Oct 2026, 22:35 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
Thin evidence
One scorer or noneExploitation evidence
Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Ubuntu 26.10linuxpkg:deb/ubuntu/linux?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-oraclepkg:deb/ubuntu/linux-oracle?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
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)