CVE-2025-22404 AI-generated analysis

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

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.

Before each L2CA_DataWrite call, the fix saves the BT_HDR length (or uses pointer arithmetic), so the failure-path log::warn statements in AVCT, BNEP, HID device, RFCOMM and SDP no longer read a buffer that the call may already have freed.

Root cause

Nine call sites pass a BT_HDR* to L2CA_DataWrite. When the call returns something other than L2CAP_DW_SUCCESS, they log p_buf->len (or hd_cb.pending_data->len, p->len or p_msg->len). Per the commit message, in exceptional cases the preceding call has already freed the buffer, so the log statement reads freed memory. The affected sites are: avct_lcb_act.cc:avct_lcb_msg_ind, bnep_main.cc:bnep_congestion_ind, bnep_utils.cc:bnepu_check_send_packet, hidd_conn.cc:hidd_check_config_done, rfc_ts_frames.cc:rfc_send_buf_uih, rfc_utils.cc:rfc_check_send_cmd, sdp_discovery.cc:process_service_attr_rsp, and sdp_server.cc:process_service_search and process_service_attr_req.

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 on the AVCT_REJ response path and logs `len` instead of `p_buf->len`.
• system/stack/bnep/bnep_main.cc:bnep_congestion_ind: in the loop that drains p_bcb->xmit_q when not congested, stores `len = p_buf->len` before L2CA_DataWrite and logs the local.
• system/stack/bnep/bnep_utils.cc:bnepu_check_send_packet: in the non-congested else branch, stores `len = p_buf->len` before L2CA_DataWrite and logs the local.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: stores `len = hd_cb.pending_data->len` before the L2CA_DataWrite of pending interrupt-channel data and logs the local. The indentation of the if block is slightly off; there is no logic change.
• system/stack/rfcomm/rfc_ts_frames.cc:rfc_send_buf_uih: for DLCIs other than the multiplexer DLCI, stores `len = p_buf->len` before L2CA_DataWrite and logs the local.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: in the cmd_q drain loop, stores `len = p->len` before L2CA_DataWrite and logs the local.
• system/stack/sdp/sdp_discovery.cc:process_service_attr_rsp: the log now uses `p - p_start` instead of `p_msg->len`. This is the value assigned to p_msg->len just before the call, so p_msg is not read after the call.
• system/stack/sdp/sdp_server.cc:process_service_search and process_service_attr_req: the logs now use `p_rsp - p_rsp_start` instead of `p_buf->len`. This is the value assigned to p_buf->len just before the send.

Completeness

• None of the nine L2CA_DataWrite failure-path logs touched by the diff reads the buffer after the call any more, and the logged values are the same as before.
• The fix only changes logging. It does not change L2CA_DataWrite or how these call sites handle the buffer. No other post-call use of the buffer is visible in the provided context.
• The title 'Fix more memory-unsafe logging' suggests an earlier commit of the same kind. The material does not show whether other L2CA_DataWrite callers outside these eight files have the same pattern.

Behavior changes

• Nothing observable changes: the log output carries the same length values, now taken from a local variable or from pointer arithmetic done before the call.

Per major

• Android 14: Not affected per the bulletin. android-security-14.0.0_r29 has 4/8 lines of the patched region. The material does not show whether the vulnerable log statements exist in this branch.
• Android 15: Same fix: commit 806774b1cf64 in android-security-15.0.0_r5 (cherry-pick of internal commit 43cfd234de9b, Change-Id I6289907e86786eb2e10a163f7fb5d2557eab00bc). At android-security-15.0.0_r17 the code context shows all nine sites patched (the resolver matched 7/8 lines).
• Android 16: Not affected per the bulletin. android-security-16.0.0_r8 has 4/8 lines of the patched region. Per index search, the indexed copy of bnepu_check_send_packet (labelled Android 15, android-15.0.0_r36) already has the `len` local and uses a refactored `stack::l2cap::get_interface().L2CA_DataWrite(...) != tL2CAP_DW_RESULT::SUCCESS` call. The lower match count may therefore reflect refactored code, but the material does not confirm this for Android 16.
• Android 17: Not affected per the bulletin. android-security-17.0.0_r1 has 4/8 lines of the patched region. Same caveat as Android 16.

Unknowns

• The material does not show which L2CA_DataWrite failure path frees the buffer, or the function's ownership contract. It only says the buffer may be freed in exceptional cases.
• The commit lists nine bug IDs. The material does not show which site belongs to this CVE's bug, or the content of the earlier 'memory-unsafe logging' commit.
• The material does not show whether Android 14/16/17 contain the vulnerable log statements, or whether a different commit fixed them there.
• How a remote peer reaches each patched site (for example, what triggers the AVCT_REJ path) is not shown.

Back to March 2025 · Findings