CVE-2024-57876: drm/dp_mst: Fix resetting msg rx state after topology removal
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Fix resetting msg rx state after topology removal
If the MST topology is removed during the reception of an MST down reply
or MST up request sideband message, the
drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset
from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with
the reading/parsing of the message from another thread via
drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is
possible since the reader/parser doesn't hold any lock while accessing
the reception state. This in turn can lead to a memory corruption in the
reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST
sideband message body length check").
Fix the above by resetting the message reception state if needed before
reading/parsing a message. Another solution would be to hold the
drm_dp_mst_topology_mgr::lock for the whole duration of the message
reception/parsing in drm_dp_mst_handle_down_rep() and
drm_dp_mst_handle_up_req(), however this would require a bigger change.
Since the fix is also needed for stable, opting for the simpler solution
in this patch.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel graphics-driver flaw involving DisplayPort multi-stream transport. A timing race during monitor topology removal can corrupt memory while the kernel processes DisplayPort sideband messages. Business urgency depends on whether affected endpoints use DisplayPort MST hardware such as docks or daisy-chained monitors.
Executive priority
Treat as a kernel maintenance priority for Linux endpoints using modern display docking, not as confirmed internet-facing emergency. Prioritize normal patch cycles unless your fleet heavily depends on DisplayPort MST or your vendor rates the backport as urgent.
Technical view
The DRM DP MST code can reset up_req_recv or down_rep_recv state during topology disable while another thread parses MST sideband messages without holding the manager lock. The kernel fix resets reception state before parsing, avoiding the race and related memory corruption described by the source commit.
Likely exposure
Most relevant exposure is Linux systems with kernels carrying the vulnerable DRM DP MST code and DisplayPort MST usage. Desktops, laptops, workstations, and docked endpoints are more plausible than headless servers. Exact exposure depends on distro backports and kernel package versions.
Exploitation context
The bundle does not show CISA KEV listing or active exploitation. The described trigger involves a race during MST topology removal while receiving sideband messages. Sources do not provide exploit prerequisites, impact beyond memory corruption, or a public weaponized path.
Researcher notes
Evidence is limited to the CVE description, stable kernel commit references, and Debian LTS advisory. No CVSS, CWE, KEV, exploit confirmation, or complete product CPE mapping is provided. Avoid assuming remote exploitability or privilege impact without vendor analysis.
Mitigation direction
Apply vendor or distribution kernel updates containing the referenced stable DRM MST fixes.
Review the Debian LTS advisory if running Debian LTS kernel packages.
Verify whether endpoint fleets use DisplayPort MST, docks, or daisy-chained displays.
If patching is delayed, consider reducing MST-dependent display setups where feasible.
Track Linux kernel and distro advisories for corrected package versions.
Validation and detection
Inventory Linux kernel versions and distro package release levels across affected fleets.
Confirm whether running kernels include one of the referenced stable commits or distro backports.
Check endpoint hardware profiles for DisplayPort MST, USB-C docks, or daisy-chained monitors.
Review kernel package changelogs for CVE-2024-57876 or the DRM DP MST fix title.
Monitor vendor advisories because the source bundle lacks CVSS and detailed affected CPEs.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-57876 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
1ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 11, 2025, 14:49 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.