CVE-2025-0075 AI-generated analysis

platform/packages/modules/Bluetooth, SDP server (system/stack/sdp/sdp_server.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.

In system/stack/sdp/sdp_server.cc process_service_search_attr_req, the warning logged when L2CA_DataWrite fails no longer reads p_buf->len, because p_buf may already have been freed. It now computes the length from the local pointers p_rsp - p_rsp_start.

Root cause

process_service_search_attr_req builds an SDP response in buffer p_buf and passes it to L2CA_DataWrite(p_ccb->connection_id, p_buf). If the call did not return L2CAP_DW_SUCCESS, the warning log read p_buf->len. The commit message says the structure may, in exceptional cases, have been freed by preceding calls, so this read could be a use after free.

How the fix works

• system/stack/sdp/sdp_server.cc:process_service_search_attr_req: in the log::warn call, the argument p_buf->len is replaced by p_rsp - p_rsp_start. These are local pointers. The code context shows p_buf->len = p_rsp - p_rsp_start being set just before the write, so the logged value is the same, but p_buf is no longer read after the call.
• No other logic changes: the write, its return check and the log text stay the same. The change is one line in one hunk.

Completeness

• The fix only changes the failure-path log in process_service_search_attr_req. Within the diff, it removes the read of p_buf after L2CA_DataWrite.
• The code context at android-security-15.0.0_r17 (lines 275-310, labeled process_service_search_attr_req) shows the log already using p_rsp - p_rsp_start. The body of that snippet writes handle counts and handles, so it is unclear whether it is the patched function or another response path. The material does not show whether any other SDP response path in sdp_server.cc reads p_buf after L2CA_DataWrite.
• The fix does not change L2CA_DataWrite itself.

Behavior changes

• None functionally. The logged length is the same number (p_rsp - p_rsp_start is the value assigned to p_buf->len before the write). Only the source of the value changes.

Per major

• Android 14: Not affected per the bulletin (not listed). At android-security-14.0.0_r29, 1/4 lines of the patched region are present. The material does not show whether the same log pattern exists.
• Android 15: Same fix: commit 5959f8bcf4ef in android-security-15.0.0_r5, cherry-picked from an internal change (Change-Id I1037e592ab8910eeae5c28a41a53a2fc60a298d8). At android-security-15.0.0_r17, 3/4 lines of the region are present, and the log uses p_rsp - p_rsp_start.
• Android 16: Not affected per the bulletin (not listed). At android-security-16.0.0_r8, 2/4 lines of the patched region are present. The material does not show the state of the patched line.
• Android 17: Not affected per the bulletin (not listed). At android-security-17.0.0_r1, 2/4 lines of the patched region are present. The material does not show the state of the patched line.

Unknowns

• Which L2CA_DataWrite paths or preceding calls free p_buf. The material only says it may be freed in exceptional cases.
• Whether other SDP response handlers in sdp_server.cc read p_buf after the write, and which function the r17 context snippet actually belongs to.
• The exact state of the patched line in the Android 14, 16 and 17 trees. Only line-match counts are given.
• Whether and how the fix is delivered through Mainline module updates.

Back to March 2025 · Findings