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 type confusion vulnerability in BluetoothServiceRecordWin allows a paired Bluetooth device to trigger an arbitrary memory read in the Chromium Device Service process on Windows. The issue arises from a failure to validate the data type of Service Discovery Protocol (SDP) elements before accessing union-mapped fields, allowing attacker-controlled integers to be misinterpreted as memory addresses.

Affected files:

• device/bluetooth/bluetooth_service_record_win.cc
• device/bluetooth/bluetooth_task_manager_win.cc
• device/bluetooth/bluetooth_device_win.cc
• services/device/serial/serial_port_manager_impl.cc
• content/browser/serial/serial_service.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Summary

A potential type confusion vulnerability has been identified in the handling of Bluetooth Service Discovery Protocol (SDP) records within the Chromium Device Service on Windows. The vulnerability exists in device/bluetooth/bluetooth_service_record_win.cc, where the code fails to verify the type discriminant of an SDP_ELEMENT_DATA structure before accessing its union members. On 64-bit systems, this leads to union punning where an attacker-controlled integer can be misinterpreted as a memory pointer, potentially leading to an arbitrary memory read or a process crash.

Root Cause Analysis

In device/bluetooth/bluetooth_service_record_win.cc, the constructor for BluetoothServiceRecordWin retrieves SDP attributes using the Windows API BluetoothSdpGetAttributeValue. The resulting SDP_ELEMENT_DATA structure contains a type field and a data union.

// device/bluetooth/bluetooth_service_record_win.cc:148-152
SDP_ELEMENT_DATA uuid_data;
if (ERROR_SUCCESS == BluetoothSdpGetAttributeValue(
                         blob_data, blob_size, kUuidId, &uuid_data)) {
  ExtractUuid(uuid_data, &uuid_);
}

The ExtractUuid function passes this data to AdvanceToSdpType, which immediately accesses the sequence member of the data union without checking if the type is actually SDP_TYPE_SEQUENCE:

// device/bluetooth/bluetooth_service_record_win.cc:23-31
bool AdvanceToSdpType(const SDP_ELEMENT_DATA& sequence_data, ... ) {
  while (ERROR_SUCCESS == BluetoothSdpGetContainerElementData(
      sequence_data.data.sequence.value,
      sequence_data.data.sequence.length,
      element,
      sdp_data)) { ... }
}

On 64-bit Windows, the data.uint128 member (16 bytes) aliases the data.sequence structure, which contains an 8-byte LPBYTE value pointer and a 4-byte ULONG length. If a malicious Bluetooth device provides an SDP attribute encoded as a UINT128, the first 8 bytes of that integer will be reinterpreted as the value pointer in AdvanceToSdpType. This causes BluetoothSdpGetContainerElementData to attempt to parse memory at an arbitrary, attacker-controlled address.

Potential Impact

The Device Service on Windows typically runs as an unsandboxed utility process (kNoSandbox). An arbitrary memory read in this process could allow an attacker to:

1. Information Leak: Exfiltrate memory contents. If the bytes at the target address can be successfully parsed as an SDP UUID element, the value is stored in the service record and can be read by a malicious webpage via SerialPort.getInfo().bluetoothServiceClassId in the Web Serial API.
2. Denial of Service: Trigger a crash of the Device Service by providing an invalid or unmapped memory address, affecting all hardware-related functionality in Chrome (Serial, HID, USB, etc.).

Suggested Potential Trigger Steps

1. An attacker-controlled Bluetooth Classic device is configured to return a UINT128 for SDP attribute ID 1 (ServiceClassIDList).
2. The attacker-controlled device is paired with a victim’s Windows machine.
3. The victim visits a site that triggers Bluetooth device enumeration (e.g., via navigator.serial.getPorts()).
4. Chrome’s Device Service polls the device’s SDP records, triggering the type confusion and subsequent arbitrary memory access.

Suggested Fix

The functions ExtractUuid and ExtractChannels should verify that the type field of the SDP_ELEMENT_DATA returned by BluetoothSdpGetAttributeValue matches the expected type (SDP_TYPE_UUID, SDP_TYPE_SEQUENCE, etc.) before further processing. Additionally, AdvanceToSdpType should include a check to ensure sequence_data.type is a valid container type (e.g., SDP_TYPE_SEQUENCE or SDP_TYPE_ALTERNATIVE) before accessing the data.sequence union member.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

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.