{"uuid": "c66f327d-48df-48d0-bca1-89980dda7d0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57876", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/1319", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57876\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn't hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\"drm/dp_mst: Fix MST\nsideband message body length check\").\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.\n\ud83d\udccf Published: 2025-01-11T14:49:02.550Z\n\ud83d\udccf Modified: 2025-01-11T14:49:02.550Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/94b33b2d7640e807869451384eb88321dd0ffbd4\n2. https://git.kernel.org/stable/c/d834d20d2e86c52ed5cab41763fa61e6071680ef\n3. https://git.kernel.org/stable/c/be826b4451fd187a7c0b04be4f8243d5df6e0450\n4. https://git.kernel.org/stable/c/a6fa67d26de385c3c7a23c1e109a0e23bfda4ec7", "creation_timestamp": "2025-01-11T15:04:34.000000Z"}