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 (UAF) vulnerability exists in the macOS browser process due to a missing callback keep-alive in BluetoothDiscoveryManagerMacClassic. On destruction, the manager releases its strong reference to BluetoothDeviceInquiryDelegate while an asynchronous callback may be enqueued on the main run loop. The subsequent callback execution on a deallocated receiver could lead to memory corruption in the unsandboxed browser process.

Affected files:

• device/bluetooth/bluetooth_discovery_manager_mac.mm

Estimated timestamp from git blame: 2014-06-13

Description

A potential Use-After-Free (UAF) vulnerability exists in device/bluetooth/bluetooth_discovery_manager_mac.mm due to a missing keep-alive mechanism for BluetoothDeviceInquiryDelegate during the destruction of BluetoothDiscoveryManagerMacClassic.

In macOS Chromium Bluetooth code, several classes use Objective-C delegates to receive asynchronous callbacks from system frameworks (such as IOBluetooth). Due to a known macOS issue (referenced internally as FB13705522), these system frameworks can enqueue asynchronous callback messages on the main thread’s run loop and capture the delegate’s raw address at enqueue time. If the owner is destroyed before these enqueued callbacks run, they will target a deallocated delegate receiver.

To mitigate this, a keep-alive campaign was implemented across sibling IOBluetooth delegate classes (e.g., in BluetoothRfcommChannelMac, BluetoothL2capChannelMac, BluetoothSocketMac, etc.) using dispatch_async to keep the delegate alive for an extra turn of the main run loop. However, BluetoothDiscoveryManagerMacClassic was missed.

Potential Root Cause

In device/bluetooth/bluetooth_discovery_manager_mac.mm, the destructor ~BluetoothDiscoveryManagerMacClassic only resets the delegate property of the inquiry object:

~BluetoothDiscoveryManagerMacClassic() override {
  inquiry_.delegate = nil;
}

Directly after this destructor body completes, the strong reference inquiry_delegate_ is released, and the BluetoothDeviceInquiryDelegate is deallocated. If an asynchronous callback was already enqueued by IOBluetooth, it will invoke objc_msgSend on the deallocated delegate pointer.

Potential Step-by-Step Trigger Sequence

Note: The following steps are theoretical and represent a potential path, as our tooling does not currently have the capability to execute code or verify exploitation dynamically:

1. A page or extension triggers Bluetooth classic scanning (e.g., via Web Serial or chrome.bluetooth.startDiscovery()).
2. BluetoothAdapterMac::StartScanWithFilter lazily initializes classic_discovery_manager_ (an instance of BluetoothDiscoveryManagerMacClassic) and starts the device inquiry via [inquiry_ start].
3. A nearby physical Bluetooth device responds, causing the macOS framework to enqueue an asynchronous delegate callback (e.g., -deviceInquiryDeviceFound:device:) on the main run loop.
4. The user closes the tab or navigates away, destroying the adapter and destroying classic_discovery_manager_ via its unique pointer.
5. ~BluetoothDiscoveryManagerMacClassic() sets inquiry_.delegate = nil and immediately deallocates inquiry_delegate_.
6. The enqueued callback on the main run loop executes, invoking objc_msgSend on the freed BluetoothDeviceInquiryDelegate address, potentially leading to memory corruption in the unsandboxed browser process.

Suggested Fix

To remediate this issue, implement the same lifetime extension workaround used by the sibling classes. Keep a strong reference to the delegate alive across one main run loop turn during destruction:

~BluetoothDiscoveryManagerMacClassic() override {
  inquiry_.delegate = nil;
  BluetoothDeviceInquiryDelegate* __strong delegate = inquiry_delegate_;
  dispatch_async(dispatch_get_main_queue(), ^{
    (void)delegate;
  });
}

Evaluated with Chrome root at commit: 208ca3371d87589335b108c431b95a36d768dc47

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.