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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential Use-After-Free vulnerability exists in the macOS implementation of Bluetooth RFCOMM and L2CAP channels. When an outgoing connection fails, the delegate’s self-retain mechanism is bypassed, and a short-term keep-alive in the destructor is insufficient to protect against late-arriving asynchronous callbacks from the OS. An attacker could intentionally delay over-the-air protocol responses to reliably trigger the UAF, potentially leading to remote code execution.

Affected files:

• device/bluetooth/bluetooth_rfcomm_channel_mac.mm
• device/bluetooth/bluetooth_l2cap_channel_mac.mm

Estimated timestamp from git blame: Unknown (Google3 checkout)

Overview

A potential Use-After-Free (UAF) vulnerability exists in the macOS implementation of Bluetooth RFCOMM and L2CAP channels, specifically within BluetoothRfcommChannelDelegate and BluetoothL2capChannelDelegate (device/bluetooth/bluetooth_rfcomm_channel_mac.mm and bluetooth_l2cap_channel_mac.mm).

To mitigate a known issue where macOS’s IOBluetooth framework may fire callbacks even after a delegate is cleared (Apple Feedback FB13705522), Chromium implements a self-retain mechanism (_strongSelf) during successful connections and a fallback short-term keep-alive in the C++ owner’s destructor. However, these protections are incomplete on the failed outgoing connection path.

Root Cause Analysis

In rfcommChannelOpenComplete:status: (and the equivalent L2CAP method), the _strongSelf self-retain is only armed if the connection is successful:

- (void)rfcommChannelOpenComplete:(IOBluetoothRFCOMMChannel*)rfcommChannel
                           status:(IOReturn)error {
  CHECK(_rfcommChannel);
  if (error == kIOReturnSuccess) {
    _strongSelf = self;   // Only armed on SUCCESS
  }
  // ...
}

When an outgoing connection fails (error != kIOReturnSuccess), _strongSelf remains nil. The delegate’s lifetime is then tied solely to its C++ owner, BluetoothRfcommChannelMac.

When the C++ owner is destroyed (typically immediately following the connection failure), its destructor attempts to protect the delegate by capturing it in a dispatch_async block, keeping it alive for exactly one main-run-loop turn:

BluetoothRfcommChannelMac::~BluetoothRfcommChannelMac() {
  [delegate_ resetOwner];
  [channel_ setDelegate:nil];
  [channel_ closeChannel];
  // One-turn keep-alive
  BluetoothRfcommChannelDelegate* __strong delegate = delegate_;
  dispatch_async(dispatch_get_main_queue(), ^{ (void)delegate; });
}

Because [channel_ closeChannel] initiates an asynchronous, over-the-air protocol teardown (e.g., an RFCOMM DISC command), the resulting rfcommChannelClosed: callback from the OS can arrive much later. If an attacker intentionally delays the protocol-level response from their malicious Bluetooth device, the one-turn keep-alive will expire, and the delegate will be deallocated. When the OS eventually receives the delayed response and fires the terminal callback on the dangling pointer, an Objective-C message is sent to freed memory.

Suggested Exploit Steps

Note: These are potential steps as our tooling agent does not have the ability to run a live Proof of Concept.

1. An attacker sets up a malicious physical Bluetooth device and places it in proximity to the victim.
2. The victim visits an attacker-controlled website, which uses the Web Serial or Web Bluetooth API to request a connection to the malicious device.
3. The malicious device accepts the initial request but intentionally rejects the RFCOMM/L2CAP protocol connection, returning an error.
4. The rfcommChannelOpenComplete:status: callback fires with an error. The _strongSelf retain is skipped, and the C++ channel object is destroyed.
5. The C++ destructor calls closeChannel (sending a disconnect command over the air) and posts the 1-turn keep-alive block.
6. The malicious device deliberately delays its acknowledgment of the disconnect command.
7. The main thread’s keep-alive block finishes executing, and the BluetoothRfcommChannelDelegate object is deallocated by ARC.
8. The attacker sprays the Browser process heap via standard Web API IPCs, replacing the freed delegate memory with controlled data (including a fake isa pointer).
9. The malicious device finally replies to the disconnect command.
10. The IOBluetooth framework (due to bug FB13705522) fires the rfcommChannelClosed: callback on the freed delegate, hijacking control flow.

Impact

Since this occurs in the highly-privileged Browser process where macOS Bluetooth services are handled, this UAF can lead to a complete Sandbox Escape and Remote Code Execution (RCE). As Objective-C objects do not typically benefit from MiraclePtr protections when passed to external frameworks, the exploitability of this issue is considered high.

Suggested Fix

Unconditionally arm the _strongSelf self-reference in the openComplete callbacks, regardless of the connection status.

- (void)rfcommChannelOpenComplete:(IOBluetoothRFCOMMChannel*)rfcommChannel
                           status:(IOReturn)error {
  CHECK(_rfcommChannel);
  // Keep the delegate alive until rfcommChannelClosed.
  _strongSelf = self;
  // ...
}

Because the OS guarantees that rfcommChannelClosed: (or the L2CAP equivalent) will eventually fire, it is safe to arm the retain cycle here; the terminal callback will accurately clear _strongSelf, breaking the cycle and allowing safe deallocation.

Evaluated with Chrome root at commit: 65b3256311f3ab6fb9870eaa522de7e6dd2663bb

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.