CVE-2025-22403 AI-generated analysis

platform/packages/modules/Bluetooth, SDP discovery (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 (7 corrections). Verify against the commit before relying on it.

Replaces two log::warn arguments in system/stack/sdp/sdp_discovery.cc. They read p_cmd->len / p_msg->len after the buffer had been passed to L2CA_DataWrite, which per the commit message may have freed it in exceptional cases. The fix logs the locally computed length p - p_start instead.

Root cause

In sdp_snd_service_search_req and process_service_search_attr_rsp, the outgoing SDP buffer (p_cmd / p_msg) is passed to L2CA_DataWrite. The commit message says that in exceptional cases the preceding call may have freed that buffer. When L2CA_DataWrite returned something other than L2CAP_DW_SUCCESS, the failure log statement dereferenced the same buffer (p_cmd->len / p_msg->len) to print the length, which could read freed memory.

How the fix works

• system/stack/sdp/sdp_discovery.cc:sdp_snd_service_search_req: the log::warn after a failed L2CA_DataWrite now prints `p - p_start` instead of dereferencing p_cmd->len. This is the same value stored in p_cmd->len at line 178.
• system/stack/sdp/sdp_discovery.cc:process_service_search_attr_rsp: the equivalent log::warn after a failed L2CA_DataWrite now prints `p - p_start` instead of dereferencing p_msg->len.
• No ownership or control-flow logic is changed. This is a single commit that changes 2 lines.

Completeness

• Covers exactly the two log statements named in the commit message. In sdp_snd_service_search_req, the shown context has no further access to p_cmd after L2CA_DataWrite. The material does not show the rest of process_service_search_attr_rsp after the write.
• The fix does not change L2CA_DataWrite's ownership/free semantics. This commit does not address any other caller that reads a buffer after passing it to L2CA_DataWrite. The material shows no such caller.
• Only the failure branch (L2CA_DataWrite != L2CAP_DW_SUCCESS) is changed. Success-path code is unchanged.

Behavior changes

• No functional change; only the length argument of a warning log changes. In sdp_snd_service_search_req the logged value is identical to the previous p_cmd->len. No new error codes, timeouts or validation.

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. The material does not show whether an equivalent post-write dereference exists.
• Android 15: Same fix: commit 37bcf769c1aa in android-security-15.0.0_r5 (cherry-pick of internal bb2f54f9ed93). At android-security-15.0.0_r17 the patched line with `p - p_start` is present in sdp_snd_service_search_req (6/8 region lines match).
• Android 16: Not affected per the bulletin. At android-security-16.0.0_r8, 4/8 lines of the patched region are present. The material does not show the exact lines.
• Android 17: Not affected per the bulletin. At android-security-17.0.0_r1, 4/8 lines of the patched region are present. The material does not show the exact lines.

Unknowns

• The material does not show the exact conditions under which L2CA_DataWrite frees the buffer and returns failure.
• The material does not show the rest of process_service_search_attr_rsp after the write, or whether p_msg->len was set to p - p_start there.
• The material does not show whether the pre-fix pattern exists in the Android 14/16/17 source; it reports only partial region matches.

Back to March 2025 · Findings