CVE-2024-0045 AI-generated analysis
platform/packages/modules/Bluetooth, system/stack/smp (BLE Security Manager Protocol, built as com.android.btservices)
Adds an SMP command length validation at the start of smp_proc_sec_req in system/stack/smp/smp_act.cc. A Security Request command with an invalid length is now rejected with SMP_INVALID_PARAMETERS instead of being parsed, which addresses an out-of-bounds read when auth_req is read from the payload.
Root cause
smp_proc_sec_req (system/stack/smp/smp_act.cc) unconditionally dereferenced p_data->p_data as a tBTM_LE_AUTH_REQ to get auth_req. It did not first check that the received Security Request command had a valid length, so a malformed command could cause a read beyond the valid command data (commit title: OOB bug in smp_proc_sec_req; bulletin type ID, information disclosure).
How the fix works
- system/stack/smp/smp_act.cc:smp_proc_sec_req: before auth_req is read, the function now calls smp_command_has_invalid_length(p_cb). If that reports an invalid length, it builds a tSMP_INT_DATA with status = SMP_INVALID_PARAMETERS, posts SMP_AUTH_CMPL_EVT to the SMP state machine via smp_sm_event, and returns without touching p_data->p_data.
- The rest of the function (btm_ble_link_sec_check and the sec_req_act switch) is unchanged and now runs only for commands that pass the length check.
- Single commit, 7 lines added. The commit does not define smp_command_has_invalid_length; it uses it as an existing function.
Completeness
- Covers only the Security Request handler smp_proc_sec_req.
- The fix depends on smp_command_has_invalid_length(p_cb) correctly assessing the received command length. The helper is not modified and its definition is not in the material.
- The commit changes no other code paths or handlers. The material does not show whether other SMP handlers that dereference p_data->p_data have the same guard.
Behavior changes
- A Security Request with an invalid length now causes SMP_AUTH_CMPL_EVT to be posted with status SMP_INVALID_PARAMETERS. The function returns early, so no encryption or pairing action is taken from that request.
- Security Requests that pass the length check are processed as before.
Per major
- Android 14: same fix: commit 16c3f8dc40b2 in android-security-14.0.0_r6 (cherry-pick of an internal change, Merged-In I400cfa3523c6d8b25c233205748c2db5dc803d1d). All 5 lines of the patched region are present at android-security-14.0.0_r29.
- Android 15: not affected (not listed by the bulletin). The patched region is fully present (5/5 lines) at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin). The patched region is fully present (5/5 lines) at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). 4/5 lines of the patched region are present at android-security-17.0.0_r1; the material does not show the difference.
Unknowns
- The material does not include the definition of smp_command_has_invalid_length or show how the expected length for the Security Request command is derived.
- The material does not show whether other SMP handlers are guarded the same way.
- What the SMP state machine does after receiving SMP_AUTH_CMPL_EVT with SMP_INVALID_PARAMETERS is not shown.
- The exact difference in the patched region at android-security-17.0.0_r1 is not shown.
- The bulletin lists Android 13 as affected, but the provided per-major facts do not show whether it got the same change.
- The material does not show whether user interaction is needed to trigger the issue, or which device role sends the triggering command.