CVE-2025-0084 AI-generated analysis
platform/packages/modules/Bluetooth, system/bta/hf_client (HFP client SDP) and system/stack/sdp (SDP discovery client)
Adds a guard in bta_hf_client_do_disc that aborts discovery when the HF client control block already owns an SDP discovery database, and a NULL check on p_ccb->p_db in process_service_search_attr_rsp that disconnects the SDP connection instead of continuing with no database.
Root cause
bta_hf_client_do_disc always allocated a new tSDP_DISCOVERY_DB into client_cb->p_disc_db with osi_malloc and set up discovery. It never checked whether the control block already held a discovery database. According to the commit message, a modified client can open two connections against the same SDP discovery database. Once the first connection closes, the second one can reference the freed database. Separately, process_service_search_attr_rsp used p_ccb->p_db without checking for NULL, and the commit adds that check to guard against unchecked use of the database.
How the fix works
- system/bta/hf_client/bta_hf_client_sdp.cc:bta_hf_client_do_disc: the new check runs after the attribute and UUID lists are built and before osi_malloc of the discovery db. If client_cb->p_disc_db != NULL, the function logs an error (APPL_TRACE_ERROR on 14, log::error on 15), sets client_cb->p_disc_db = NULL, forces client_cb->state = 0 (BTA_HF_CLIENT_INIT_ST) and returns. It does not allocate a second database or start a second discovery. Per the code comment, the state is set by hand because the function can be entered from the OPEN state, where a discovery-fail event would be ignored.
- system/stack/sdp/sdp_discovery.cc:process_service_search_attr_rsp: in the branch that sends the continuation or first-time request, if p_ccb->p_db == NULL the function logs a warning (SDP_TRACE_WARNING on 14, log::warn on 15), calls sdp_disconnect(p_ccb, tSDP_STATUS::SDP_INVALID_CONT_STATE) and returns before using the database. This catches only a NULL pointer, not a dangling one.
- The commit message names the flag com.android.bluetooth.flags.btsec_check_valid_discovery_database, but neither diff shown contains a flag check. In the shown diffs, both checks run unconditionally.
Completeness
- Covers the HF client entry point that allocates the discovery database (bta_hf_client_do_disc) and one SDP response handler (process_service_search_attr_rsp), which gets a NULL p_db check.
- Only process_service_search_attr_rsp received the p_db NULL check. The sibling response handlers in sdp_discovery.cc are not in the diff, and the material does not show whether they use p_ccb->p_db without a check.
- The guard in bta_hf_client_do_disc sets the existing p_disc_db pointer to NULL. It does not free that database or tear down the earlier SDP connection, and the material does not show how the old database is eventually released.
- Only the HF client profile's discovery setup is guarded. Other profiles that allocate SDP discovery databases are outside the diff and not shown in the material.
Behavior changes
- A second bta_hf_client_do_disc call on a control block that already has a discovery database now logs an error, resets the control block state to BTA_HF_CLIENT_INIT_ST and returns without starting discovery. Previously it allocated a second database.
- process_service_search_attr_rsp now logs a warning and ends the SDP connection with tSDP_STATUS::SDP_INVALID_CONT_STATE when p_ccb->p_db is NULL. Previously it carried on.
Per major
- Android 14: same fix: commit c4d8043ef4ea in android-security-14.0.0_r18, using APPL_TRACE_ERROR / SDP_TRACE_WARNING. All 6 lines of the patched region are present at android-security-14.0.0_r29.
- Android 15: adapted fix: commit 94c565214e34 in android-security-15.0.0_r6, with identical logic but log::error / log::warn logging. All 6 lines of the patched region are present at android-security-15.0.0_r17.
- Android 16: not affected: not listed by the bulletin. All 6 lines of the patched region are present at android-security-16.0.0_r8.
- Android 17: not affected: not listed by the bulletin. All 6 lines of the patched region are present at android-security-17.0.0_r1.
Unknowns
- How two SDP connections come to share one discovery database in the unpatched code path. The commit message describes this only at a high level.
- Where the freed database is actually used after the first connection closes. The NULL check in process_service_search_attr_rsp does not catch a dangling pointer.
- Whether other response handlers in sdp_discovery.cc use p_ccb->p_db without a check (not in the material).
- What happens to the existing database that the new guard drops by setting client_cb->p_disc_db = NULL (whether it is freed elsewhere or leaked).
- Whether the flag com.android.bluetooth.flags.btsec_check_valid_discovery_database gates this code anywhere. The diffs shown contain no flag check.
- Whether bta_hf_client_start_open calls bta_hf_client_do_disc (the index snippet is cut off).