CVE-2026-98786 json
drm/amd/display: guard dc_sink dereferences in MST mode validation
published 24d ago modified yesterday also EUVD-2026-103871
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 6%
- public exploits
- 0
- none known
Summary
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)
Patch / fix
- Linux Linux 7.3
- linux Debian 14 7.2.10-1
debian advisories DEBIAN-CVE-2026-98786
- linux Ubuntu 26.04 LTS 7.0.0-43.43
- linux-aws Ubuntu 26.04 LTS 7.0.0-1017.18
- linux-gcp Ubuntu 26.04 LTS 7.0.0-1017.19
- linux-gke Ubuntu 26.04 LTS 7.0.0-1010.11
- linux-ibm Ubuntu 26.04 LTS 7.0.0-1018.18
- linux-azure Ubuntu 26.04 LTS 7.0.0-1020.21
- linux-oracle Ubuntu 26.04 LTS 7.0.0-1016.18
- linux-aws-7.0 Ubuntu 24.04 LTS 7.0.0-1017.18~24.04.1
ubuntu advisories UBUNTU-CVE-2026-98786
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
Is CVE-2026-98786 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-98786 updated cvss 4.7
kernel: drm/amd/display: guard dc_sink dereferences in MST mode validation
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: no fix available “Fix deferred”
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.17% chance of exploitation in the next 30 days, higher than 6% of all scored CVEs (FIRST EPSS, 2026-11-11).
Affected products
- Linux Linux
Classification
- Technology feeds
References
Sources
- CVE List CVE-2026-98786
- NVD CVE-2026-98786
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.