Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The RestoreTokenManager singleton in WebRTC’s Wayland desktop capture module lacks any synchronization for its shared state. Concurrent mutation of an internal std::unordered_map from the Browser UI thread and dedicated capture threads can lead to heap corruption or use-after-free. This vulnerability resides in the unsandboxed browser process and is reachable from web content via screen capture requests.

Affected files:

• third_party/webrtc/modules/desktop_capture/linux/wayland/restore_token_manager.cc
• third_party/webrtc/modules/desktop_capture/linux/wayland/restore_token_manager.h
• third_party/webrtc/modules/desktop_capture/linux/wayland/base_capturer_pipewire.cc

Estimated timestamp from git blame: 2022-06-06

Description

A potential data race exists in the RestoreTokenManager class used by the PipeWire-based desktop capturer on Linux/Wayland. RestoreTokenManager is a process-wide singleton that manages restore tokens using a std::unordered_map and an integer counter, both of which are accessed without any synchronization primitives (such as mutexes or atomics).

// third_party/webrtc/modules/desktop_capture/linux/wayland/restore_token_manager.h
  DesktopCapturer::SourceId last_source_id_ = 0;
  std::unordered_map<DesktopCapturer::SourceId, std::string> restore_tokens_;

In Chromium, this singleton is accessed concurrently from different threads within the browser process:

1. Browser UI Thread: On Linux, the UI thread pumps the global GLib main context. The BaseCapturerPipeWire class uses asynchronous GDBus signals to communicate with the XDG Desktop Portal. When a portal response is received (e.g., in OnScreenCastRequestResult), the callback is executed on the UI thread. This callback calls RestoreTokenManager::AddToken, which performs a std::unordered_map::insert operation.
2. Desktop Capture Threads: Each capture session runs on a dedicated desktopCaptureThread. These threads call RestoreTokenManager::GetToken (during BaseCapturerPipeWire::Start) and RestoreTokenManager::GetUnusedId (during BaseCapturerPipeWire::EnsureVisible). GetToken uses the operator[], which is a mutating operation in C++ (it inserts a default value if the key is not found).

Impact

Concurrent unsynchronized mutation of a std::unordered_map is undefined behavior. If one thread triggers a rehash of the map while another thread is accessing it, it can result in a heap use-after-free (UAF) or corruption of the map’s internal bucket structure. Since this occurs in the browser process, which is not sandboxed, it could potentially be leveraged for an escape from the renderer sandbox and arbitrary code execution with the user’s privileges.

Potential Steps to Reproduce

Note: These are suggested steps; our analysis is based on code review.

1. On a Linux Wayland system, open a web page that initiates multiple desktop capture requests (e.g., multiple calls to navigator.mediaDevices.getDisplayMedia()).
2. Rapidly accept the system-level capture prompts. This forces the browser to handle multiple asynchronous portal responses on the UI thread while the capture threads are simultaneously initializing or restarting capture sessions.
3. Under a ThreadSanitizer (TSAN) build, a data race on RestoreTokenManager::restore_tokens_ should be detected between the UI thread and the background capture threads.
4. Under AddressSanitizer (ASAN), the race may manifest as a heap-use-after-free during map rehashing.

Suggested Fix

Protect all accesses to restore_tokens_ in RestoreTokenManager with a mutex (e.g., webrtc::Mutex). Additionally, last_source_id_ should be changed to a std::atomic<DesktopCapturer::SourceId> or also be protected by the mutex.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.