CVE-2026-98786: drm/amd/display: guard dc_sink dereferences in MST mode validation
drm/amd/display: guard dcsink dereferences in MST mode validation
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.15-1Fixed in 7.3.3-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.117 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.61 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 7c3db8da4e039698ae198c870712428644e965c7
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's AMD display driver in DisplayPort Multi-Stream Transport (MST) configurations are exposed when a sink is unplugged while mode validation is running.
What event triggers the vulnerable race?
The race occurs when MST teardown clears dc_sink asynchronously while either the connector probe worker runs its mode_valid callback or a compositor performs an atomic check. Neither of those paths holds the MST manager lock used by teardown.
What is the impact if the race occurs?
The affected paths can dereference a NULL dc_sink while reading DSC capabilities or HDMI-PCON FRL bandwidth capabilities. The fix instead fails the port-support check or skips FRL conversion when the sink is gone.
Does the existing dsc_aux NULL check prevent this issue?
No. dsc_aux is not reliably cleared on every path that clears dc_sink, so checking dsc_aux does not ensure that dc_sink is valid.