CVE-2023-40090 AI-generated analysis
platform/packages/modules/Bluetooth, system/stack/btm (BLE security, LE data signature verification)
Replaces the plain memcmp used to compare the computed AES-CMAC with the received signature in BTM_BleVerifySignature with BoringSSL's CRYPTO_memcmp, which is hardened against timing side channels.
Root cause
In system/stack/btm/btm_ble.cc, BTM_BleVerifySignature computes an AES-CMAC over the signed data with the peer's CSRK (p_rec->ble.keys.pcsrk) via crypto_toolbox::aes_cmac into p_mac. It then compared p_mac with the received signature p_comp using the stock memcmp over BTM_CMAC_TLEN_SIZE bytes. The commit message says this stock memcmp allows signature contents to be deduced through a side-channel (timing) attack. The bulletin rates the issue High / EoP.
How the fix works
- system/stack/btm/btm_ble.cc:BTM_BleVerifySignature: the comparison `memcmp(p_mac, p_comp, BTM_CMAC_TLEN_SIZE) == 0` becomes `CRYPTO_memcmp(p_mac, p_comp, BTM_CMAC_TLEN_SIZE) == 0`. Per the commit message, CRYPTO_memcmp is hardened against this timing attack.
- system/stack/btm/btm_ble.cc: adds `#include "openssl/mem.h"` to declare CRYPTO_memcmp.
- On success the existing logic is unchanged: btm_ble_increment_sign_ctr(bd_addr, false) is called and verified is set to true.
Completeness
- The fix covers exactly one MAC comparison, in BTM_BleVerifySignature. The MAC computation and the sign-counter handling around it are not changed.
- This commit changes no other comparison sites. The material does not show whether other secret comparisons in the Bluetooth stack use memcmp, so nothing can be concluded about them.
- The fix is a one-line semantic change plus an include. The diff adds no new validation, error path or test. The commit message names atest bluetooth_test_gd_unit as the test run.
Behavior changes
- None functionally: CRYPTO_memcmp returns 0 on equality, so the existing `== 0` check keeps the same verification outcome. Only the timing of the comparison changes.
- btm_ble.cc now includes BoringSSL's openssl/mem.h.
Per major
- Android 14: same fix: commit fb76b30e0210 in android-security-14.0.0_r3 (cherry-pick of 7a960ac1c0cbc6d3949b6eaa7a86302a0b20c04f). At android-security-14.0.0_r29, 8/8 lines of the patched region are present.
- Android 15: not affected per the bulletin. At android-security-15.0.0_r17, 6/8 lines of the patched region are present. The material does not identify the two differing lines.
- Android 16: not affected per the bulletin. At android-security-16.0.0_r8, 6/8 lines of the patched region are present. The material does not identify the two differing lines.
- Android 17: not affected per the bulletin. At android-security-17.0.0_r1, 6/8 lines of the patched region are present. The material does not identify the two differing lines.
Unknowns
- The callers of BTM_BleVerifySignature and the transport path to it (for example, which ATT/GATT operations) are not shown in the material.
- The material does not show which 2 of the 8 patched-region lines differ at the Android 15/16/17 tags, or whether CRYPTO_memcmp is present there. It shows only that the bulletin lists those versions as not affected.
- The Android 13 fix commit is not in the material.