CVE-2025-22409 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 (8 corrections). Verify against the commit before relying on it.

Nine failure-path log statements in the Bluetooth stack (AVCT, BNEP, HID device, RFCOMM, SDP) read the buffer length after passing the buffer to L2CA_DataWrite. They now use a length captured before the call, or a pointer difference that was already computed, so they no longer read a buffer that may already have been freed.

Root cause

Several stack layers followed the same pattern: call L2CA_DataWrite(cid, p_buf), and if it does not return L2CAP_DW_SUCCESS, call log::warn("Unable to write L2CAP data ... len:{}", ..., p_buf->len). Per the commit message, the buffer may, in exceptional cases, have been freed by the preceding call, so the log argument read a possibly freed buffer. Affected sites: avct_lcb_act.cc:avct_lcb_msg_ind (AVCT_REJ packet), bnep_main.cc:bnep_congestion_ind (draining xmit_q), bnep_utils.cc:bnepu_check_send_packet, hidd_conn.cc:hidd_check_config_done (hd_cb.pending_data), rfc_ts_frames.cc:rfc_send_buf_uih, rfc_utils.cc:rfc_check_send_cmd (draining cmd_q), 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 and logs `len` instead of p_buf->len.
• system/stack/bnep/bnep_main.cc:bnep_congestion_ind: inside the dequeue loop, captures `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 branch, captures `len` before L2CA_DataWrite and logs the local.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: captures `len = hd_cb.pending_data->len` before L2CA_DataWrite(p_hcon->intr_cid, hd_cb.pending_data) and logs the local. The new block is badly indented, but the logic is otherwise 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 the local.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: inside the cmd_q drain loop, captures `len = p->len` before L2CA_DataWrite 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.
• 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.
• L2CA_DataWrite itself and the control flow are unchanged. Only the log arguments change, so they no longer depend on the buffer after the call.

Completeness

• Covers nine L2CA_DataWrite failure-log sites across eight files. At each site, the buffer is no longer read after the call.
• The fix is entirely at the call sites. L2CA_DataWrite's behavior on failure is unchanged, so any other caller that touches the buffer after a failed L2CA_DataWrite would still be affected. The material does not show the full set of L2CA_DataWrite callers.
• The commit title 'Fix more memory-unsafe logging' suggests an earlier related change covered other sites. That change is not in the material.
• The hidd_conn.cc hunk introduces misaligned indentation but is functionally correct.

Behavior changes

• No functional change: the same warning messages are logged with the same length value, now taken before the write call. At the SDP sites, the logged length is the pointer difference that was just assigned to the len field.

Per major

• Android 14: Not affected per the bulletin (not listed). At android-security-14.0.0_r29, 4/8 lines of the patched region are present.
• Android 15: Fixed by commit 806774b1cf64 in android-security-15.0.0_r5 (cherry-picked from internal commit 43cfd234de9b, Change-Id I6289907e86786eb2e10a163f7fb5d2557eab00bc). At android-security-15.0.0_r17, 7/8 lines of the patched region are present. The context there shows the fixed form at eight of the nine sites; the avct_lcb_msg_ind hunk is not shown in the context.
• Android 16: Not affected per the bulletin (not listed). At android-security-16.0.0_r8, 4/8 lines of the patched region are present.
• Android 17: Not affected per the bulletin (not listed). At android-security-17.0.0_r1, 4/8 lines of the patched region are present.

Unknowns

• The failure paths inside L2CA_DataWrite that free the buffer before returning a non-success code are not in the material.
• Which of the nine sites the 'researcher POC' exercised, and which of the nine bug IDs maps to which site.
• The earlier companion commit implied by the title 'Fix more memory-unsafe logging', and the sites it covered.
• Whether other L2CA_DataWrite callers outside these eight files still read the buffer after a failed write.
• Why only 4/8 patched-region lines match on Android 14, 16 and 17, and whether those branches have the same pattern.
• Whether the avct_lcb_msg_ind fix is present at android-security-15.0.0_r17 (not shown in the context).

Back to March 2025 · Findings