CVE-2025-0074 AI-generated analysis

platform/packages/modules/Bluetooth, SDP client (system/stack/sdp/sdp_discovery.cc)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (5 corrections). Verify against the commit before relying on it.

Two log::warn statements in system/stack/sdp/sdp_discovery.cc read p_cmd->len / p_msg->len after a failed L2CA_DataWrite. They now log the locally computed length (p - p_start), so the buffer that may have been freed is no longer dereferenced.

Root cause

In sdp_snd_service_search_req and process_service_search_attr_rsp, the outgoing SDP PDU buffer (p_cmd / p_msg) is passed to L2CA_DataWrite. When L2CA_DataWrite does not return L2CAP_DW_SUCCESS, the code emits a log::warn whose arguments read p_cmd->len / p_msg->len. The commit message says that in exceptional cases the preceding call has already freed that structure, so the log statement reads freed memory.

How the fix works

• system/stack/sdp/sdp_discovery.cc:sdp_snd_service_search_req: after a failed L2CA_DataWrite, the log::warn now logs `p - p_start` (the value stored into p_cmd->len on line 178 at r17) instead of dereferencing p_cmd->len.
• system/stack/sdp/sdp_discovery.cc:process_service_search_attr_rsp: the equivalent log::warn after a failed L2CA_DataWrite now logs `p - p_start` instead of p_msg->len.
• L2CA_DataWrite ownership semantics are unchanged; the fix only removes the two post-call reads of the buffer. The commit is labelled a trivial logic fix and lists a researcher POC as a test.

Completeness

• The fix covers exactly the two L2CA_DataWrite failure log statements named in the commit (sdp_snd_service_search_req and process_service_search_attr_rsp). Both now use only local variables.
• In the shown context for sdp_snd_service_search_req, the buffer is not touched after L2CA_DataWrite: the function goes on to alarm_set_on_mloop with p_ccb. The material does not show the rest of process_service_search_attr_rsp.
• The material does not show whether other L2CA_DataWrite call sites in sdp_discovery.cc or elsewhere in the SDP stack have the same post-write logging pattern.

Behavior changes

• No functional change. Only the memory read in the warning path is removed. In sdp_snd_service_search_req the logged value matches what was stored in p_cmd->len (apart from the uint16_t cast). The material does not show the matching assignment for p_msg->len.

Per major

• Android 14: Not affected per the bulletin. At android-security-14.0.0_r29 only 2/8 lines of the patched region are present, so the region differs from the Android 15 code.
• Android 15: Same fix: commit 37bcf769c1aa in android-security-15.0.0_r5, a cherry-pick with Change-Id I1c8816721588acba9110257b61b4e993cf2720d6. At android-security-15.0.0_r17, 6/8 lines of the patched region are present, and the shown context has the fixed `p - p_start` argument in sdp_snd_service_search_req.
• Android 16: Not affected per the bulletin. At android-security-16.0.0_r8, 4/8 lines of the patched region are present, so the region differs from the Android 15 code.
• Android 17: Not affected per the bulletin. At android-security-17.0.0_r1, 4/8 lines of the patched region are present, so the region differs from the Android 15 code.

Unknowns

• The material does not show the exact failure conditions under which the buffer is freed before the log statement.
• The material does not show whether other L2CA_DataWrite call sites in the SDP stack have similar post-write logging.
• The material does not show why Android 16 and 17 are not listed by the bulletin, beyond the line-presence counts.
• The material does not show the full context of process_service_search_attr_rsp around the fixed site.

Back to March 2025 · Findings