CVE-2026-98786 in Linux
Summary
by MITRE • 10/18/2026
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)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's display manager subsystem, specifically the AMD Display driver component responsible for managing Multi-Stream Transport (MST) configurations, contained a critical concurrency flaw involving asynchronous resource teardown and race conditions. The vulnerability centers on two specific functions: dm_dp_mst_is_port_support_mode() and get_conv_frl_bw(). These routines are invoked during mode validation processes to determine display capabilities such as Display Stream Compression branch throughput and HDMI-PCON FRL bandwidth limits, respectively. Both functions attempt to access members of the dc_sink structure, specifically dsc_caps and edid_caps.max_frl_rate, without verifying whether the pointer is valid. This lack of defensive programming creates a direct path for memory corruption or kernel panic when the underlying hardware state changes unexpectedly during operation.
The root cause lies in the asynchronous nature of MST connector unplug events versus the synchronous execution paths of display mode validation. When an MST hub or monitor is disconnected, the driver initiates a teardown sequence that clears the dc_sink pointer to release associated resources. However, this cleanup process acquires the MST manager lock to ensure safe modification of shared state. In contrast, the functions triggering the vulnerability are executed from two distinct contexts: the connector probe worker's mode_valid callback and a compositor's atomic check routine. Neither of these execution paths holds the MST manager lock during their operation. Consequently, there is a significant window where the dc_sink pointer may be set to NULL by the teardown thread while one of these validation functions is actively attempting to dereference it. This classic use-after-free or null-pointer dereference scenario arises because the driver's own documentation acknowledges that these paths race against the teardown process, yet the code fails to account for this reality in its access patterns.
The operational impact of this vulnerability can range from a simple display mode validation failure resulting in a black screen or fallback to lower resolutions, to more severe consequences such as kernel oopses, system crashes, or potential privilege escalation if an attacker can manipulate timing to trigger the race condition during sensitive memory operations. In the context of modern desktop environments where compositors frequently query display capabilities for window management and scaling decisions, this flaw could be triggered by normal user interactions involving hot-plugging devices or rapid mode changes. The existing mitigation within dm_dp_mst_is_port_support_mode(), which checks if dsc_aux is NULL, proves insufficient because the dsc_aux pointer is not reliably cleared in every code path that clears dc_sink. Therefore, relying on auxiliary structure validity does not guarantee protection against dereferencing a freed or nullified main sink object.
To mitigate this vulnerability, developers must implement explicit NULL checks before accessing any members of the dc_sink structure within these validation functions. The fix involves failing the port-support check and skipping the FRL conversion path immediately if the sink is determined to be unavailable due to asynchronous teardown. This approach ensures that the driver gracefully handles race conditions without crashing or corrupting memory. From a standards perspective, this issue aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed or invalidated, and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, highlighting the failure to properly synchronize access between threads managing resource lifecycles. Furthermore, in terms of adversarial tactics, this type of race condition can be leveraged for Denial of Service attacks against graphical subsystems, mapping to MITRE ATT&CK technique T1499: Endpoint Denial of Service. Ensuring that all asynchronous teardown paths properly synchronize with validation routines or employ reference counting mechanisms is essential for maintaining the stability and security of kernel-level display drivers.