CVE-2023-24023 AI-generated analysis

platform/packages/modules/Bluetooth, system/stack/btm (BTM security manager, btm_sec.cc)

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

The Bluetooth stack now caches a bonded BR/EDR peer's Secure Connections support when its link key is notified. When peer security capabilities arrive on a new connection, it disconnects the link if the peer reports a downgrade from Secure Connections mode (a BLUFFS mitigation).

Root cause

In system/stack/btm/btm_sec.cc, btm_sec_set_peer_sec_caps took the sc_supported value the remote reported on each connection and went on to record the peer's capabilities (remote_feature_received and related fields) without comparing it to a value observed when the device was bonded. btm_sec_link_key_notification did not cache the bonded peer's Secure Connections support either. Nothing therefore rejected a reconnection on which a peer bonded with Secure Connections reported no Secure Connections support.

How the fix works

• system/stack/btm/btm_sec.cc:btm_sec_link_key_notification: after link key handling, if p_dev_rec->is_bond_type_persistent() and the device is BR/EDR or dual mode, the function calls btm_sec_store_device_sc_support(p_dev_rec->get_br_edr_hci_handle(), p_dev_rec->SupportsSecureConnections()) to cache the peer's Secure Connections support.
• system/stack/btm/btm_sec.cc:btm_sec_set_peer_sec_caps: right after it finds the device record by handle, the function calls btm_sec_is_device_sc_downgrade(hci_handle, sc_supported). If that reports a downgrade, it calls acl_set_disconnect_reason(HCI_ERR_HOST_REJECT_SECURITY), then btm_sec_send_hci_disconnect(p_dev_rec, HCI_ERR_AUTH_FAILURE, hci_handle, "attempted to downgrade from Secure Connections mode"), and returns before remote_feature_received and the other capability fields are updated.
• Android 15 (f904fd5ad7ef): removes the bluffs_mitigation aconfig flag from flags/security.aconfig and the com::android::bluetooth::flags::bluffs_mitigation() guards in btm_sec.cc. This makes the following always active: the Secure Connections downgrade check, the SC support caching, and the encryption key size downgrade check (btm_sec_is_session_key_size_downgrade / btm_sec_update_session_key_size in read_encryption_key_size_complete_after_encryption_change). It also deletes the flag-off branch of btm_sec_encryption_change_evt that skipped the key size read when set_min_encryption was enabled and SET_MIN_ENCRYPTION_KEY_SIZE was supported.

Completeness

• The Android 14 commit only adds the connection-time check for Secure Connections mode, as its commit message states. The encryption key size downgrade check visible in the Android 15 code is not part of this diff, and the material does not show whether Android 14 has that check.
• SC support is cached only for records with a persistent bond type that are BR/EDR or dual mode. How the downgrade check behaves for records with no cached value is not shown.
• The downgrade check relies on btm_sec_store_device_sc_support and btm_sec_is_device_sc_downgrade, which this diff does not define. The material does not show their storage semantics (in-memory or persisted).
• On a detected downgrade, the function returns before remote_feature_received and the other peer capabilities are recorded.

Behavior changes

• When btm_sec_is_device_sc_downgrade reports a Secure Connections downgrade for a connection, the stack disconnects the link with HCI_ERR_AUTH_FAILURE and sets the ACL disconnect reason to HCI_ERR_HOST_REJECT_SECURITY.
• Secure Connections support is now cached at link key notification time for persistently bonded BR/EDR or dual-mode devices.
• On Android 15 the mitigation is no longer gated by the bluffs_mitigation flag. For successful, enabled encryption changes on non-LE links, the encryption key size is read and checked for a downgrade whenever the controller supports READ_ENCRYPTION_KEY_SIZE. The flag-off path that skipped this when SET_MIN_ENCRYPTION_KEY_SIZE was in use is removed.

Per major

• Android 14: same fix: b5155f0591f9 in android-security-14.0.0_r12 adds the SC support caching and the downgrade check with no flag guard. 6/6 lines of the patched region are present at android-security-14.0.0_r29.
• Android 15: adapted fix: the mitigation was guarded by the bluffs_mitigation aconfig flag. f904fd5ad7ef in android-security-15.0.0_r5 removes the flag, so the SC check and the key size downgrade check are always on. Device record fields are accessed via p_dev_rec->sec_rec. 4/8 lines of the patched region are present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin). 5/6 lines of the patched region are present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin). 0/6 lines of the patched region are present at android-security-17.0.0_r1.

Unknowns

• Whether the encryption key size downgrade check seen in the Android 15 code was also applied to Android 14. Only the Secure Connections mode CL is shown for 14.
• Definitions and storage semantics of btm_sec_store_device_sc_support and btm_sec_is_device_sc_downgrade (in-memory or persisted across restarts), and how they behave when no value is cached.
• The bulletin's affected list says 13, 14, 15, 16-next, while the per-major facts say Android 16 is not listed. The material does not reconcile this.
• Which caller delivers remote features to btm_sec_set_peer_sec_caps (the index search found only a test mock).
• Android 13 status: the bulletin lists it as affected, but the material gives no commit or tag for it.
• Why only 4/8 (15), 5/6 (16) and 0/6 (17) lines of the patched region match in the later tags.

Back to September 2025 · Findings