Description
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)
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)
Published:
2026-10-18
Score:
n/a
EPSS:
n/a
KEV:
No
Impact:
n/a
Action:
n/a
Analysis and contextual insights are available on OpenCVE Cloud.
Remediation
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Sun, 18 Oct 2026 16:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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) | |
| Title | drm/amd/display: guard dc_sink dereferences in MST mode validation | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-10-18T15:48:22.989Z
Reserved: 2026-09-25T10:25:14.370Z
Link: CVE-2026-98786
No data.
Status : Received
Published: 2026-10-18T16:17:32.580
Modified: 2026-10-18T16:17:32.580
Link: CVE-2026-98786
No data.
OpenCVE Enrichment
No data.
Weaknesses
No weakness.