Cloudanix VulnDB

CVE-2026-98786

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in AMD graphics drivers can crash computers when certain multi-monitor setups are unplugged while the system is checking display modes.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Race condition allowing NULL dc_sink dereference in dm_dp_mst_is_port_support_mode and get_conv_frl_bw during MST unplug, triggered from mode_valid and atomic_check paths without the MST manager lock.

Why it matters to the business

Kernel instability or crashes on systems using AMD GPUs with DisplayPort MST hubs or docks, potentially causing display failures and system downtime.

How an attack unfolds

An attacker with local access or a malicious display device triggers rapid MST unplug events while the connector probe worker or compositor atomic check runs, racing against asynchronous dc_sink teardown to hit the unguarded pointer access.

How to fix it

Apply the upstream fix from commit 7c3db8da4e039698ae198c870712428644e965c7 or later kernel versions that add the dc_sink NULL guards in MST validation paths; rebuild and reboot with patched kernel.

How to confirm the fix worked

Confirm kernel source contains the added NULL checks before dc_sink dereferences in dm_dp_mst_is_port_support_mode and get_conv_frl_bw; test by exercising MST connect/unplug under load with atomic commits.

Typical attack path

  1. Connect MST display device
  2. Initiate unplug or hot-unplug sequence
  3. Trigger concurrent mode validation or atomic check from userspace or compositor
  4. Exploit window where dc_sink is cleared without lock held
  5. Cause NULL dereference leading to kernel panic or oops

How to detect it

Search kernel logs for oops or panic traces mentioning dm_dp_mst_is_port_support_mode, get_conv_frl_bw, dc_sink, or MST teardown races; correlate with recent unplug events in dmesg or journalctl.

  • dm_dp_mst_is_port_support_mode
  • get_conv_frl_bw
  • dc_sink
  • MST manager lock
  • dsc_aux NULL check

What your security team should do

  • Prioritize kernel update on all AMD GPU systems within 7 days given recency
  • Monitor for display-related kernel crashes post-unplug events
  • Disable MST if not required on high-risk endpoints until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: guard dc_sink dereferences in MST mode validation dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this. Fail the port-support check and skip the FRL conversion path when the sink is already gone. (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7)

Affected packages

Ecosystem Package Introduced Fixed