CVE-2025-22405 AI-generated analysis

platform/packages/modules/Bluetooth, system/stack (AVCT, BNEP, HID device, 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 (6 corrections). Verify against the commit before relying on it.

At nine Bluetooth stack call sites in eight files, the failure log after L2CA_DataWrite() no longer reads the BT_HDR buffer that was passed to that call (the commit message says such a buffer may already be freed). The length is now saved in a local variable before the call or recomputed from existing pointers.

Root cause

At each affected site the code calls L2CA_DataWrite(cid, p_buf). Per the commit message, in exceptional cases the buffer may have been freed by that call. When the call does not return L2CAP_DW_SUCCESS, the log::warn("Unable to write L2CAP data ...") statement read p_buf->len (or hd_cb.pending_data->len, p->len, p_msg->len) from a buffer that may already be freed. This is a read use-after-free in the warning path.

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(p_lcb->ch_lcid, p_buf) and logs `len` instead of p_buf->len in the AVCT_REJ send path.
• system/stack/bnep/bnep_main.cc:bnep_congestion_ind: in the uncongested drain loop over p_bcb->xmit_q, saves `len = p_buf->len` before L2CA_DataWrite(l2cap_cid, p_buf) and logs the local.
• system/stack/bnep/bnep_utils.cc:bnepu_check_send_packet: in the direct-send else branch, saves `len = p_buf->len` before L2CA_DataWrite(p_bcb->l2cap_cid, p_buf) and logs the local.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: saves `len = hd_cb.pending_data->len` before L2CA_DataWrite(p_hcon->intr_cid, hd_cb.pending_data) and logs the local. hd_cb.pending_data is still set to NULL afterwards. The new lines are mis-indented, but the logic is correct.
• system/stack/rfcomm/rfc_ts_frames.cc:rfc_send_buf_uih: for DLCIs other than RFCOMM_MX_DLCI, saves `len = p_buf->len` before L2CA_DataWrite(p_mcb->lcid, p_buf) and logs the local.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: in the cmd_q drain loop, saves `len = p->len` before L2CA_DataWrite(p_mcb->lcid, p) and logs the local.
• system/stack/sdp/sdp_discovery.cc:process_service_attr_rsp: logs `p - p_start` (the value just assigned to p_msg->len) instead of p_msg->len after L2CA_DataWrite(p_ccb->connection_id, p_msg).
• system/stack/sdp/sdp_server.cc:process_service_search and process_service_attr_req: log `p_rsp - p_rsp_start` (the value just assigned to p_buf->len) instead of p_buf->len after L2CA_DataWrite(p_ccb->connection_id, p_buf).

Completeness

• The fix removes the read of the written buffer after the call at all nine changed call sites. At each site the logged length is the same value as before, either saved before the call or recomputed from pointers into the caller's own state.
• The fix changes only the call sites. It does not change how L2CA_DataWrite takes ownership of or frees the buffer, so any other L2CA_DataWrite caller that reads the buffer after the call would need the same change. The commit title 'Fix more memory-unsafe logging' suggests an earlier related commit, which is not in this material.
• The other values in the log statements (p_lcb->peer_addr, p_bcb->rem_bda, p_mcb->bd_addr, p_ccb->device_address, the cids) come from control blocks, not from the written buffer, and the fix leaves them unchanged.

Behavior changes

• No functional change: only the source of the length value in the warning log messages changes.
• The hidd_conn.cc hunk changes indentation only. Control flow is the same.

Per major

• Android 14: Not affected per the bulletin (Android 14 is not listed). At android-security-14.0.0_r29, 4/8 lines of the patched region are present.
• Android 15: Same fix: commit 806774b1cf64 in android-security-15.0.0_r5, a cherry-pick of internal commit 43cfd234de9b (Change-Id I6289907e86786eb2e10a163f7fb5d2557eab00bc). At android-security-15.0.0_r17, 7/8 lines of the patched region are present, and the code context there shows all nine call sites fixed.
• Android 16: Not affected per the bulletin (Android 16 is not listed). At android-security-16.0.0_r8, 4/8 lines of the patched region are present. The material does not show the Android 16 code.
• Android 17: Not affected per the bulletin (Android 17 is not listed). At android-security-17.0.0_r1, 4/8 lines of the patched region are present. The material does not show the Android 17 code.

Unknowns

• The exact conditions under which L2CA_DataWrite frees the buffer and returns a non-success result.
• Which call sites the researcher POC exercised, and which of the nine bug IDs maps to CVE-2025-22405.
• The content of any earlier 'memory-unsafe logging' commit that this change extends.
• What code Android 14, 16 and 17 have at these sites (only partial line matches are reported).

Back to March 2025 · Findings