CVE-2025-22411 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.

In nine log::warn statements across the AVCT, BNEP, HID device, RFCOMM and SDP layers of the Bluetooth stack, the fix stops reading the BT_HDR buffer's len field after the buffer has been passed to L2CA_DataWrite. It either captures the length in a local before the call or recomputes it with pointer arithmetic.

Root cause

In each changed site, the log statement in the failure branch after L2CA_DataWrite still dereferenced the buffer just passed to it (p_buf->len, p->len, p_msg->len, hd_cb.pending_data->len). The commit message says these structures 'may, in exceptional cases, have been freed by preceding calls', so the logging could read freed memory.

How the fix works

• system/stack/avct/avct_lcb_act.cc:avct_lcb_msg_ind: copies p_buf->len into a local uint16_t len before L2CA_DataWrite and logs len instead of p_buf->len (AVCT_REJ response path).
• system/stack/bnep/bnep_main.cc:bnep_congestion_ind: in the uncongested drain loop over p_bcb->xmit_q, stores p_buf->len in a local before L2CA_DataWrite and logs the local.
• system/stack/bnep/bnep_utils.cc:bnepu_check_send_packet: in the non-congested branch, stores p_buf->len in a local before L2CA_DataWrite and logs the local.
• system/stack/hid/hidd_conn.cc:hidd_check_config_done: stores hd_cb.pending_data->len in a local before L2CA_DataWrite(p_hcon->intr_cid, hd_cb.pending_data) and logs the local. The new lines are indented wrongly in the diff, but the logic is not affected.
• system/stack/rfcomm/rfc_ts_frames.cc:rfc_send_buf_uih: for DLCIs other than the multiplexer DLCI, stores p_buf->len in a local before L2CA_DataWrite and logs the local.
• system/stack/rfcomm/rfc_utils.cc:rfc_check_send_cmd: in the cmd_q drain loop, stores p->len in a local before L2CA_DataWrite and logs the local.
• system/stack/sdp/sdp_discovery.cc:process_service_attr_rsp: logs p - p_start instead of p_msg->len. This is the same value assigned to p_msg->len just before the call, so the buffer is not touched.
• system/stack/sdp/sdp_server.cc:process_service_search and process_service_attr_req: log p_rsp - p_rsp_start instead of p_buf->len. This is the value previously written into p_buf->len.
• The fix does not change L2CA_DataWrite itself; it only removes reads of the buffer after the call.

Completeness

• Covers nine L2CA_DataWrite error-log sites in eight files. After the fix, none of the changed sites touches the buffer after the call.
• The commit title, 'Fix more memory-unsafe logging', points to earlier fixes of the same pattern. The material does not show those earlier commits, or whether other L2CA_DataWrite callers in system/stack still read the buffer after the call.
• In hidd_conn.cc only the hidd_check_config_done path is changed. The material does not show any other L2CA_DataWrite sites in that file.
• L2CA_DataWrite is not modified. The fix is limited to the call sites.

Behavior changes

• None functionally. Only the source of the length value in log::warn messages changes; the logged values match the intended length (a local copy, or the same pointer difference that was stored into len).

Per major

• Android 14: Not affected: the bulletin does not list Android 14. At android-security-14.0.0_r29 only 4/8 lines of the patched region are present. The material does not show whether the vulnerable log statements exist on that branch.
• 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. Per index search (android-15.0.0_r36), bnepu_check_send_packet captures the local len before a stack::l2cap::get_interface().L2CA_DataWrite call.
• Android 16: Not affected: the bulletin does not list Android 16. At android-security-16.0.0_r8, 4/8 lines of the patched region are present.
• Android 17: Not affected: the bulletin does not list Android 17. At android-security-17.0.0_r1, 4/8 lines of the patched region are present.

Unknowns

• Which conditions inside L2CA_DataWrite (or other preceding calls) free the buffer; L2CA_DataWrite is not shown.
• Whether other L2CA_DataWrite call sites in system/stack still read the buffer after the call; the commit describes 'more' fixes, but the earlier commits are not provided.
• Why the bulletin lists only Android 15; the per-major line-match counts do not settle whether the pattern exists on 14, 16 and 17.
• Details of the researcher POC referenced in the commit message.

Back to March 2025 · Findings