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: A logic error in WebRTC’s JsepTransportCollection::RollbackTransports uses short-circuiting (&&) when invoking callbacks. This allows an attacker to skip transport updates for certain transceivers during rollback by intentionally causing prior callbacks to fail (e.g., via SSRC conflicts). The bypassed transceivers retain dangling raw pointers to pending transports that are unconditionally freed at the end of the rollback process.

Affected files:

• third_party/webrtc/pc/jsep_transport_collection.cc
• third_party/webrtc/pc/channel.h
• third_party/webrtc/pc/channel.cc

Estimated timestamp from git blame: 2025-04-07

Root Cause Analysis

A potential Use-After-Free (UAF) exists in WebRTC’s transport rollback mechanism. In third_party/webrtc/pc/jsep_transport_collection.cc, the RollbackTransports function restores BaseChannel instances to their stable RtpTransport assignments. The iteration looks like this:

  bool ret = true;
  // ...
  // Next, restore old mappings.
  for (const auto& kv : stable_mid_to_transport_) {
    auto it = mid_to_transport_.find(kv.first);
    if (it == mid_to_transport_.end() || it->second != kv.second) {
      ret = ret && map_change_callback_(kv.first, kv.second); // Potential short-circuit
    }
  }
  mid_to_transport_ = stable_mid_to_transport_;
  // ...
  DestroyUnusedTransports(); // Unconditional destruction

The boolean variable ret tracks the success of the map_change_callback_ (which eventually calls BaseChannel::SetRtpTransport). If any invocation returns false, ret becomes false. Because C++ uses short-circuit evaluation for the logical AND (&&) operator, the right-hand side map_change_callback_ is not executed for any subsequent elements in the loop.

Despite this failure, the function proceeds to unconditionally reset mid_to_transport_ and calls DestroyUnusedTransports(). This destroys any RtpTransport instances created for the pending state.

If a transceiver’s callback is skipped due to the short-circuit, its BaseChannel is never instructed to disconnect from its pending transport. The channel’s RtpTransportInternal* rtp_transport_ field (third_party/webrtc/pc/channel.h) remains pointing to the pending transport. Once DestroyUnusedTransports() frees that transport, rtp_transport_ becomes a dangling raw pointer. Note that rtp_transport_ is a raw C++ pointer, meaning it is not protected by MiraclePtr/base::raw_ptr.

Potential Exploitation Scenario

We do not yet have a working proof of concept, but the following steps suggest how an attacker could exploit this logic flaw from malicious JavaScript:

1. Stable State: Establish an RTCPeerConnection with three transceivers. Assign them MIDs "A", "B", and "E" to control the alphabetical iteration order of the internal flat_map. Bundle all three transceivers onto a single JsepTransport.
2. Malicious Offer: Apply a remote SDP offer (setRemoteDescription) that:
   • Splits the BUNDLE groups: "A" on one transport, and "B" and "E" on a second transport.
   • Injects the exact same a=ssrc value for both "A" and "B".
3. Bypassing Validation: WebRTC’s ApplyRemoteDescription lacks global SSRC duplicate validation. It relies on the RtpDemuxer to detect conflicts. Because "A" and "B" are placed on different BUNDLE transports (and thus different demuxers), no conflict is detected, and the pending offer is applied successfully.
4. Rollback: Initiate a rollback (setLocalDescription({type: 'rollback'})).
5. Triggering the Conflict: RollbackTransports iterates in alphabetical order ("A", then "B", then "E").
   • "A" successfully restores to the stable demuxer, registering its malicious SSRC.
   • "B" attempts to restore to the same stable demuxer. RtpDemuxer::AddSink detects that "B"’s SSRC conflicts with the SSRC just registered by "A". The callback fails and returns false.
6. Short-Circuit and UAF: Due to ret becoming false, the map_change_callback_ for "E" is skipped entirely due to short-circuiting. "E"’s channel retains its raw pointer to its pending transport. DestroyUnusedTransports() then frees the pending transport.
7. Remote Code Execution: The attacker can reclaim the freed RtpTransportInternal object using JS heap-spraying techniques. Any subsequent operation on transceiver "E" (e.g., closing the PeerConnection) will dereference the dangling pointer. Because RtpTransportInternal is polymorphic, calling a virtual method (like UnregisterRtpDemuxerSink) allows the attacker to hijack the instruction pointer and achieve RCE in the renderer process.

Suggested Fix

Ensure that the short-circuiting behavior is removed so that all transceivers are processed during a rollback, even if previous ones fail. For example, use the bitwise AND operator (&) or a temporary variable to force evaluation:

bool success = map_change_callback_(kv.first, kv.second);
ret = ret && success;

Evaluated with Chrome root at commit: 7353d249d9cacf9c7218e1d7b8a39cf39c72d646

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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.