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 Bluetooth socket implementation when an SDP query times out. If the timeout fires, the strong reference to the SDPQueryListener delegate is released, immediately deallocating it while the macOS IOBluetooth framework still holds an unsafe_unretained reference to it. When the late callback or internal query completion eventually fires, the OS dispatches a selector to the deallocated object, potentially causing a browser process crash or arbitrary code execution.

Affected files:

• device/bluetooth/bluetooth_socket_mac.mm

Estimated timestamp from git blame: 2024-06-13

Problem Description

In device/bluetooth/bluetooth_socket_mac.mm, SDPQueryListener is registered as the target of -[IOBluetoothDevice performSDPQuery:], a legacy macOS system API. Because the macOS IOBluetooth framework dates back to early versions of macOS, it stores its target/delegate using an unsafe_unretained (raw) pointer to avoid strong reference cycles.

Chromium’s only strong reference keeping the SDPQueryListener alive is the sdp_query_listener_ instance variable in BluetoothSocketMac (declared as SDPQueryListener* __strong sdp_query_listener_; in the header).

When an SDP query takes longer than the local 10-second watchdog timer, BluetoothSocketMac::OnSDPQueryTimeout() is executed. It clears the callback and resets the listener pointer:

void BluetoothSocketMac::OnSDPQueryTimeout() {
  DCHECK(thread_checker_.CalledOnValidThread());
  if (!sdp_query_listener_) {
    return;
  }
  auto error_callback = [sdp_query_listener_ takeErrorCallback];
  if (error_callback) {
    std::move(error_callback).Run(kSDPQueryTimeout);
  }
  sdp_query_listener_ = nil;   // Sole strong reference is dropped, deallocating the listener
}

Resetting sdp_query_listener_ to nil immediately deallocates the SDPQueryListener instance. However, the OS-level SDP query is still running asynchronously in the background. When the query eventually completes (or times out at the system level), the OS Bluetooth framework attempts to invoke -sdpQueryComplete:status: on the deallocated pointer, causing a Use-After-Free inside objc_msgSend.

Since the Device/Bluetooth Service runs inside the unsandboxed Browser process on macOS due to TCC system entitlement constraints, this issue could potentially be leveraged to escape the browser sandbox and execute arbitrary code with browser privileges.

Potential Steps to Trigger the Vulnerability

Note: Our analysis is static and based on code review; we do not currently have an active runtime test environment to execute a proof of concept.

1. A user selects a paired, malicious Bluetooth Classic device via a Web Bluetooth/Web Serial chooser prompt.
2. The renderer requests a connection, initiating BluetoothSocketMac::Connect and dispatching [device performSDPQuery:sdp_query_listener_] with a 10-second local watchdog timer.
3. The malicious Bluetooth device intentionally delays responding to the SDP query for more than 10 seconds.
4. The 10-second timer expires, and BluetoothSocketMac::OnSDPQueryTimeout drops the reference, immediately deallocating the SDPQueryListener object under ARC.
5. The attacker attempts to reclaim the freed memory layout by spraying the heap (e.g., via Mojo or other browser allocations) to establish a fake isa pointer and method cache.
6. The malicious Bluetooth device finally sends the SDP response, prompting the OS to call -sdpQueryComplete:status: on the dangling target pointer, triggering a control flow hijack.

Suggested Remediation

Since macOS does not provide a reliable API to cancel a pending SDP query once dispatched to IOBluetoothDevice, the SDPQueryListener must not be deallocated until the OS callback is received.

To safely resolve this:

1. When a timeout occurs, clear the internal references to prevent processing the callback, but do not immediately deallocate the listener.
2. Have the SDPQueryListener hold a strong self-reference (__strong id selfKeepAlive = self;) when it is orphaned/detached from the C++ socket.
3. Release this self-reference at the very end of sdpQueryComplete:status:, ensuring that the object is safely kept alive until the OS is done interacting with it.

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

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.