Live › vulnerability › CVE-2026-98786
Go to dashboardA race in the AMD display driver can dereference a cleared DisplayPort MST sink pointer when a monitor is unplugged during mode validation. The likely result is a kernel crash (denial of service); the sources do not describe code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the amdgpu display driver (AMD Radeon GPUs) and DisplayPort MST hubs or daisy-chained monitors, where monitors are hot-unplugged. Headless servers and systems without AMD display hardware are unlikely to be affected. The sources do not say more.
No product ranges from the sources yet.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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)
This page as .md · .json · in your agent: get_signal("CVE-2026-98786")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.