A new security vulnerability was discovered: CVE-2025-26441. This issue lies in the add_attr function of sdp_discovery.cc—a core component found in Bluetooth Service Discovery Protocol (SDP) implementations. Due to a missing bounds check during attribute parsing, remote attackers could trigger an out-of-bounds read, potentially leaking memory information. No user interaction is needed, and no extra privileges are required for an attacker to exploit this bug.

In this long read, we’ll break down the problem in plain English, explore impacted code, walk through the exploit scenario, and provide references for further reading.

What’s the Problem?

The Bluetooth SDP lets devices discover each other's capabilities over a wireless network. When a vulnerable device receives and processes specially crafted SDP data, it calls add_attr—but fails to check if it's reading past the bounds of the data buffer. This slip-up can lead to an out-of-bounds read, exposing sensitive memory contents to remote attackers.

A Look at the Vulnerable Code

Here’s a simplified (and anonymized for clarity) snipplet from the add_attr function as seen in some open-source Bluetooth stacks:

// Vulnerable code in sdp_discovery.cc (simplified)
bool add_attr(attr_list_t* list, uint8_t* data, size_t len) {
    size_t offset = ;
    while (offset < len) {
        // Missing bounds check before reading 
        uint16_t attr_id = (data[offset] << 8) | data[offset + 1];
        offset += 2;
        uint8_t attr_len = data[offset];
        offset += 1;
        // Process attribute value that could extend past data buffer!
        memcpy(list->attrs[attr_id], data + offset, attr_len);
        offset += attr_len;
    }
    return true;
}

What’s wrong here?
The code reads from the buffer without checking if there are at least two bytes before reading attr_id, or whether there’s enough left in the buffer for attr_len bytes.

How Can Attackers Exploit This?

An attacker controlling the SDP response can craft a payload where offset + 1 or offset + attr_len goes past the input buffer. Since there’s no check, the code reads out-of-bounds memory and sends it back, potentially exposing private data like stack addresses or secrets.

The kicker: This attack is remote (works over Bluetooth) and needs zero user interaction. An attacker just needs the victim’s Bluetooth adapter within range and listening for SDP queries.

Setup: The attacker gets close enough to the victim device with Bluetooth active.

2. Serve Malicious SDP Payload: Attacker crafts a short buffer, sets attr_len to a large value, so the code reads past the real end.
3. Trigger Processing: The vulnerable function parses the attack data, reads extra bytes from memory, and returns this chunk (or leaks data).
4. Harvest Sensitive Information: The attacker captures the leaked memory, which might include secret info, Bluetooth stack internals, or useful values for further attacks.

Example Malicious Payload

# Python: Creating an overflow buffer for SDP
payload = bytearray()
payload += b'\x00\x01'                     # attr_id
payload += b'\x20'                         # attr_len (32 bytes inline, even if buffer is only 5 bytes left)
payload += b'A' * 2                        # Only 2 bytes, will read 30 unknown bytes from memory
# Send this as part of SDP service record to victim

Help attackers chain exploits for arbitrary code execution

Important: There is NO need for any victim interaction.

A robust fix should add proper bounds checks before reading from the data buffer. Example mitigation

if (offset + 2 > len) return false; // check attr_id
uint16_t attr_id = (data[offset] << 8) | data[offset + 1];
offset += 2;
if (offset + 1 > len) return false; // check attr_len
uint8_t attr_len = data[offset];
offset += 1;
if (offset + attr_len > len) return false; // check attribute value

References

- NVD Entry for CVE-2025-26441 (will go live soon)
- Bluetooth SIG – SDP Documentation
- Common C/C++ Out-of-Bounds Attack Techniques
- Example Fix in BlueZ Project

Summary

CVE-2025-26441 is a memory safety bug in Bluetooth SDP protocol handling that could expose private information to any attacker within range. This happens because of missing bounds checks in the add_attr function of sdp_discovery.cc. All developers and vendors using affected Bluetooth stacks should review and patch their software as soon as possible.

Stay tuned for more updates as official advisories and patches are released.

Disclaimer:
This writeup is for educational and defensive use only. Never attempt to exploit vulnerabilities on devices you do not own or have explicit permission to test.

Timeline

Published on: 09/04/2025 18:15:43 UTC
Last modified on: 09/08/2025 14:15:47 UTC