CVE-2025-22407 AI-generated analysis

platform/packages/modules/Bluetooth, system/stack (avct, bnep, hid, rfcomm, sdp)

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.

Across nine L2CA_DataWrite call sites in the Bluetooth stack (AVCT, BNEP, HID device, RFCOMM, SDP), the failure-path log::warn no longer dereferences the BT_HDR buffer that was passed to L2CA_DataWrite; instead the length is stored in a local before the call or recomputed from pointer arithmetic.

Root cause

Several stack layers call L2CA_DataWrite(cid, p_buf). When it returns something other than L2CAP_DW_SUCCESS, they log a warning that reads p_buf->len (or hd_cb.pending_data->len, p->len, p_msg->len). Per the commit message, the structures used in these log statements may, in exceptional cases, have been freed by the preceding call, so the log can read a field of freed memory. Affected functions: avct_lcb_msg_ind (avct_lcb_act.cc), bnep_congestion_ind (bnep_main.cc), bnepu_check_send_packet (bnep_utils.cc), hidd_check_config_done (hidd_conn.cc), rfc_send_buf_uih (rfc_ts_frames.cc), rfc_check_send_cmd (rfc_utils.cc), process_service_attr_rsp (sdp_discovery.cc), process_service_search and process_service_attr_req (sdp_server.cc).

How the fix works

• system/stack/avct/avct_lcb_act.cc:avct_lcb_msg_ind: adds 'uint16_t len = p_buf->len;' before L2CA_DataWrite and logs 'len' instead of p_buf->len in the AVCT_REJ send failure path.
• system/stack/bnep/bnep_main.cc:bnep_congestion_ind: in the un-congest drain loop, captures 'uint16_t len = p_buf->len;' after dequeue and before L2CA_DataWrite; the warn logs 'len'.
• system/stack/bnep/bnep_utils.cc:bnepu_check_send_packet: in the non-congested branch, captures len before L2CA_DataWrite and logs it.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: captures 'uint16_t len = hd_cb.pending_data->len;' before L2CA_DataWrite(p_hcon->intr_cid, hd_cb.pending_data) and logs 'len'. The new block is indented irregularly, but the logic is unchanged.
• system/stack/rfcomm/rfc_ts_frames.cc:rfc_send_buf_uih: in the non-MX-DLCI branch, captures len before L2CA_DataWrite and logs it.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: in the cmd_q drain loop, captures 'uint16_t len = p->len;' after dequeue and before L2CA_DataWrite; logs 'len'.
• system/stack/sdp/sdp_discovery.cc:process_service_attr_rsp: replaces p_msg->len in the warn with 'p - p_start', the same expression just assigned to p_msg->len, so p_msg is not dereferenced after the write.
• system/stack/sdp/sdp_server.cc:process_service_search and process_service_attr_req: replace p_buf->len in the warn with 'p_rsp - p_rsp_start', the value just stored into p_buf->len, so p_buf is not dereferenced after the write.
• No change to L2CA_DataWrite itself; only the logging after the call stops dereferencing the buffer.

Completeness

• Covers nine L2CA_DataWrite failure-path log statements in eight files. In each shown site, the only buffer access after the call was the ->len read in log::warn, and that read is removed.
• The fix does not change L2CA_DataWrite. Any other site that dereferences a buffer after passing it to L2CA_DataWrite would need the same treatment. The commit title 'Fix more memory-unsafe logging' suggests an earlier commit addressed other sites, but that commit is not in the material.
• The logged value is the same before and after the fix: len is captured just before the call, and the SDP pointer differences equal the value assigned to ->len immediately before, so no diagnostics are lost.

Behavior changes

• None observable: same log text and values; no new error codes, return values, or control-flow changes.

Per major

• Android 14: not affected per the bulletin; at android-security-14.0.0_r29 only 4/8 patched-region lines match. The exact state of these log statements on 14 is not shown in the material.
• Android 15: same fix: commit 806774b1cf64 in android-security-15.0.0_r5 (cherry-pick of internal 43cfd234de9b, Change-Id I6289907e86786eb2e10a163f7fb5d2557eab00bc). At android-security-15.0.0_r17, 7/8 patched-region lines are present. The code context there shows the patched form at eight of the nine sites; the avct_lcb_msg_ind site is not shown in that context.
• Android 16: not affected per the bulletin; at android-security-16.0.0_r8 4/8 patched-region lines match. The material does not show the state of the individual sites.
• Android 17: not affected per the bulletin; at android-security-17.0.0_r1 4/8 patched-region lines match. The material does not show the state of the individual sites.

Unknowns

• Under exactly which L2CA_DataWrite failure conditions the buffer is freed before return (the L2CAP implementation is not in the material).
• The earlier commit implied by 'Fix more memory-unsafe logging', and whether any other buffer dereferences after L2CA_DataWrite remain elsewhere in the stack.
• Why only 7/8 patched-region lines match at android-security-15.0.0_r17.
• Exact state of these log statements on Android 14, 16 and 17 (only line-match counts are provided).

Back to March 2025 · Findings