CVE-2024-34722 AI-generated analysis

platform/packages/modules/Bluetooth, system/stack/smp (BLE Security Manager Protocol, legacy pairing)

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.

Adds a new SMP control-block flag, SMP_PAIR_FLAGS_CMD_CONFIRM_SENT, which is set when the local Pairing Confirm is sent. smp_proc_init and smp_proc_rand now reject a peer rand received in BLE legacy pairing before the local confirm was sent, and fail the pairing with SMP_INVALID_PARAMETERS.

Root cause

In system/stack/smp/smp_act.cc, smp_proc_init (and smp_proc_rand, an identical function on branches from sc-dev to udc-dev) stored the peer's random value into p_cb->rrand after only smp_command_has_invalid_parameters(). They did not check whether the local device had already sent its own Pairing Confirm. Per the fix's comment, in legacy pairing the peer should send its rand only after the local confirm. Per the commit message, when BLE legacy pairing is initiated from the remote side, authentication can be bypassed.

How the fix works

• Commit 317b4e293cef (android-security-14.0.0_r10), system/stack/smp/smp_int.h: defines SMP_PAIR_FLAGS_CMD_CONFIRM_SENT (1 << 9) next to the existing SMP_PAIR_FLAG* bits. p_cb->flags is uint16_t, so bit 9 fits.
• Same commit, system/stack/smp/smp_act.cc:smp_send_confirm: after smp_send_cmd(SMP_OPCODE_CONFIRM, p_cb), it sets p_cb->flags |= SMP_PAIR_FLAGS_CMD_CONFIRM_SENT to record that the local confirm has gone out.
• Same commit, smp_act.cc:smp_proc_init: adds a check after smp_command_has_invalid_parameters() and before STREAM_TO_ARRAY into p_cb->rrand. If loc_auth_req and peer_auth_req do not both carry SMP_SC_SUPPORT_BIT (legacy pairing) and the CONFIRM_SENT flag is clear, it builds tSMP_INT_DATA with status SMP_INVALID_PARAMETERS, raises SMP_AUTH_CMPL_EVT via smp_sm_event, and returns without saving the rand.
• Commit 6ad3d749f7f6 (android-security-14.0.0_r16), smp_act.cc:smp_proc_rand: adds the same legacy-pairing ordering check. Its commit message says that on branches from sc-dev to udc-dev, SMP has two identical functions, smp_proc_init and smp_proc_rand. Both have the problem, and the first commit patched only smp_proc_init.

Completeness

• After both commits, both handlers in smp_act.cc (smp_proc_init and smp_proc_rand) refuse a peer rand in legacy pairing unless the local confirm was sent. The code at android-security-14.0.0_r29 shows the check in both functions.
• On Android 14, and on other branches that have smp_proc_rand, the first commit alone is incomplete, as the second commit's message states.
• The check is skipped when both loc_auth_req and peer_auth_req carry SMP_SC_SUPPORT_BIT (Secure Connections pairing). The fix does not change the Secure Connections flow.
• The diff does not show where SMP_PAIR_FLAGS_CMD_CONFIRM_SENT is cleared. Clearing the flag between pairings is not visible in the material.

Behavior changes

• In legacy (non-Secure Connections) pairing, a peer rand that arrives before the local Pairing Confirm was sent now ends the pairing with SMP_AUTH_CMPL_EVT and status SMP_INVALID_PARAMETERS. Before the fix, the rand was stored in p_cb->rrand.
• smp_send_confirm now sets a new flag bit (1 << 9) in p_cb->flags each time it runs. The fix does not change the no-op test mocks for these functions in system/test/mock/mock_stack_smp_act.h (per index search).

Per major

• Android 14: Same fix, applied in two commits: 317b4e293cef (flag, smp_send_confirm, smp_proc_init) in android-security-14.0.0_r10, then 6ad3d749f7f6 (smp_proc_rand) in android-security-14.0.0_r16. At android-security-14.0.0_r29, 8/8 lines of the patched region are present.
• Android 15: Not affected: the bulletin does not list Android 15. At android-security-15.0.0_r17, 7/8 lines of the patched region are present.
• Android 16: Not affected: the bulletin does not list Android 16. At android-security-16.0.0_r8, 6/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, 5/8 lines of the patched region are present.

Unknowns

• Where p_cb->flags, and with it the new CONFIRM_SENT bit, is cleared between pairings. This is not shown in the material.
• The fix commits and code shape on the Android 15/16/17 branches. Only line-match counts are given. The bulletin facts list '15-next' as an affected version, while the per-major facts say Android 15 is not listed.
• Which SMP state-machine events route to smp_proc_init and which to smp_proc_rand. The state table is not included.
• The attack vector and the privilege required. The material does not state them.

Back to January 2025 · Findings