← WebKit — 2026-W35

9ba6cb68fcfbb1948bc4b6a1d3f88c4d9073e032  Race on RemoteVideoDecoderCallbacks::m_timestampToDuration leads to use-after-free

severity low class Race confidence 0.5 signal score 6.3 Source/WebKit/WebProcess
Primitive: concurrent access to m_timestampToDuration StdUnorderedMap from decoder callbacks
Triage note: Adds m_timestampToDurationLock guarding insert_or_assign/find/erase on m_timestampToDuration and makes m_isClosed std::atomic. addDuration vs notifyDecodingResult can run on different threads, so this fixes a real data race on an unordered_map, but impact is limited (duration values) and partly reads as TSan-driven hardening.
Structural signals: msg_strong (+3.0), msg_medium (+2.0), surgical (+1.3)

Commit message

Race on RemoteVideoDecoderCallbacks::m_timestampToDuration leads to use-after-free
rdar://177096608

Reviewed by Jean-Yves Avenard.

RemoteVideoDecoderCallbacks::addDuration is called from the JS thread that invoked VideoDecoder.decode.
RemoteVideoDecoderCallbacks::notifyDecodingResult is called from the LibWebRTCCodecs work queue.
Both mutate m_timestampToDuration so we need to add a lock to ensure synchronization.
We also make m_isClosed atomic on both the decoder and encoder callback objects as it is written in a thread and read in another.

Patch mostly written by Simon Lewis.

* LayoutTests/http/wpt/webcodecs/videoDecoder-concurrent-decode-output-no-crash-expected.txt: Added.
* LayoutTests/http/wpt/webcodecs/videoDecoder-concurrent-decode-output-no-crash.html: Added.
* Source/WebKit/WebProcess/GPU/media/RemoteVideoCodecFactory.cpp:
(WebKit::RemoteVideoDecoderCallbacks::addDuration):
(WebKit::RemoteVideoDecoderCallbacks::takeDuration):
(WebKit::RemoteVideoDecoderCallbacks::notifyDecodingResult):

Originally-landed-as: 305413.1093@safari-7624.5-branch (50232798d951). rdar://185369402
Canonical link: https://commits.webkit.org/319863@main

Before / after

Loading diff…