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

Across nine L2CA_DataWrite call sites in the Bluetooth stack (AVCTP, BNEP, HID device, RFCOMM, SDP), the failure-path log statement is changed to use a length captured before the call (a local variable or a pointer difference) instead of reading the BT_HDR buffer, which may have been freed by the time the log runs.

Root cause

In several stack modules the code called L2CA_DataWrite(cid, p_buf) and, if the result was not L2CAP_DW_SUCCESS, ran log::warn("Unable to write L2CAP data ... len:{}", ..., p_buf->len). The commit message says these structures may, in exceptional cases, already have been freed by the preceding call. The log argument therefore read a possibly freed BT_HDR (p_buf->len, p->len, p_msg->len, hd_cb.pending_data->len).

How the fix works

• system/stack/avct/avct_lcb_act.cc:avct_lcb_msg_ind: in the AVCT_REJ send path, 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: in the loop that drains the transmit queue after congestion clears, stores `len = p_buf->len` after the dequeue and before L2CA_DataWrite; the log uses `len`.
• system/stack/bnep/bnep_utils.cc:bnepu_check_send_packet: in the non-congested branch, stores `len` before L2CA_DataWrite and logs it.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: stores `len = hd_cb.pending_data->len` before L2CA_DataWrite(p_hcon->intr_cid, hd_cb.pending_data) and logs `len`; hd_cb.pending_data is still set to NULL afterwards.
• 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 it.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: in the loop that drains cmd_q, stores `len = p->len` after the dequeue and before L2CA_DataWrite; the log uses `len`.
• system/stack/sdp/sdp_discovery.cc:process_service_attr_rsp: the log now uses `p - p_start`, the same value just assigned to p_msg->len, so p_msg is no longer read after the write.
• system/stack/sdp/sdp_server.cc:process_service_search and process_service_attr_req: the log now uses `p_rsp - p_rsp_start`, the value just assigned to p_buf->len, instead of `p_buf->len`.
• Control flow and return values are unchanged; only the value passed to the log statement changes (plus re-indentation in hidd_conn.cc).

Completeness

• Covers nine log sites after L2CA_DataWrite in eight files: avct_lcb_act.cc, bnep_main.cc, bnep_utils.cc, hidd_conn.cc (hidd_check_config_done only), rfc_ts_frames.cc, rfc_utils.cc, sdp_discovery.cc and sdp_server.cc (two sites).
• The fix only removes the stale read in the log statement. It does not change L2CA_DataWrite or add ownership tracking, so any other code that touches a BT_HDR after passing it to L2CA_DataWrite is not addressed by this commit.
• The commit title 'Fix more memory-unsafe logging' suggests an earlier change of the same kind. That change is not in the material, so the full set of sites fixed across the series cannot be judged.
• In hidd_conn.cc only hidd_check_config_done is patched; the material does not show whether other L2CA_DataWrite call sites exist in that file.

Behavior changes

• None functional. The logged length is the same value, either stored before the call or computed from the same pointer difference that set the len field.

Per major

• Android 14: Not affected per the bulletin. At android-security-14.0.0_r29 only 4/8 lines of the patched region match; the material does not show whether the pattern is present there.
• 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 lines are present, and the code context there shows the fixed form at every site it includes (sdp_server.cc process_service_attr_req is not shown).
• Android 16: Not affected per the bulletin. At android-security-16.0.0_r8, 4/8 lines of the patched region match; the material shows no Android 16 code, so it cannot tell whether the fix form is present.
• Android 17: Not affected per the bulletin. At android-security-17.0.0_r1, 4/8 lines of the patched region match; the material shows no Android 17 code.

Unknowns

• The earlier commit implied by 'Fix more memory-unsafe logging' and which sites it covered.
• The code path inside L2CA_DataWrite that frees the buffer before returning a non-success result.
• Which of the nine sites the 'researcher POC' exercised.
• Whether the Android 14, 16 and 17 trees contain the pre-fix pattern or the fixed form at the sites where line matching failed.
• Why only 7/8 patched lines match at android-security-15.0.0_r17.

Back to March 2025 · Findings