CVE-2026-28627 AI-generated analysis

platform/packages/modules/Bluetooth, BR/EDR security manager (system/stack/btm/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 (3 corrections). Verify against the commit before relying on it.

In btm_sec_encrypt_change, a BR/EDR Encryption Change event reporting HCI_ENCRYPT_MODE_ON (E0 encryption) is now checked with btm_sec_is_enc_algo_downgrade and, if the device previously used Secure Connections, the link is disconnected with HCI_ERR_AUTH_FAILURE instead of being accepted as encrypted.

Root cause

When the controller reported an Encryption Change event with encr_enable == HCI_ENCRYPT_MODE_ON on the BR/EDR transport, btm_sec_encrypt_change simply set encryption_algo to E0 and proceeded to treat the link as encrypted (btm_sec_check_pending_enc_req had already run and bta_dm_on_encryption_change was notified). No check compared this against the device's stored security properties. Per the commit message, if both host and controller had previously supported Secure Connections, a peer could force legacy authentication (non-SC link key type) and the stack would accept the weaker link as encrypted, i.e. an implicit encryption downgrade.

How the fix works

• system/stack/btm/btm_sec.cc:btm_sec_encrypt_change: inside the `if (!from_key_refresh)` block, in the `encr_enable == HCI_ENCRYPT_MODE_ON` branch, a new `if (transport == BT_TRANSPORT_BR_EDR)` sub-block calls btm_sec_is_enc_algo_downgrade(handle, 0, 0).
• If it returns true, the fix calls acl_set_disconnect_reason(HCI_ERR_HOST_REJECT_SECURITY), then btm_sec_send_hci_disconnect(p_device, HCI_ERR_AUTH_FAILURE, handle, "attempted to downgrade from Secure Connections mode"), and returns early, so bta_dm_on_encryption_change is not invoked for the downgraded link.
• The HCI_ENCRYPT_MODE_ON_BR_EDR_AES_CCM branch and the LE path are left unchanged; the check is only added where E0 is implied on BR/EDR.
• The commit message lists aconfig flag com.android.bluetooth.flags.btsec_check_implicit_encryption_downgrade, but the diff itself contains no flag check; whether gating happens inside btm_sec_is_enc_algo_downgrade is not shown.

Completeness

• Covers the BR/EDR Encryption Change path with encr_enable == HCI_ENCRYPT_MODE_ON when from_key_refresh is false; the decision is fully delegated to btm_sec_is_enc_algo_downgrade(handle, 0, 0), whose implementation is not in the material.
• The key-refresh path (from_key_refresh == true) skips the whole block and therefore is not checked by this fix.
• The check runs after btm_sec_check_pending_enc_req(p_device, transport, ...) has already been called with encryption reported as enabled and after sec_flags were updated; the fix relies on the subsequent disconnect rather than preventing those earlier updates.
• The AES-CCM branch and LE transport are untouched (not downgrade cases by this definition).

Behavior changes

• BR/EDR links that become E0-encrypted while the device record indicates Secure Connections was previously in use are now disconnected with HCI reason HCI_ERR_AUTH_FAILURE and ACL disconnect reason HCI_ERR_HOST_REJECT_SECURITY.
• In that case bta_dm_on_encryption_change is not called, so upper layers do not receive an encryption change notification for the downgraded link.
• New log string: "attempted to downgrade from Secure Connections mode".
• Possibly gated by aconfig flag btsec_check_implicit_encryption_downgrade (per commit message; not visible in the diff).

Per major

• Android 14: not affected per bulletin; at android-security-14.0.0_r29 only 1/6 patched-region lines present, fix not applied
• Android 15: not affected per bulletin; at android-security-15.0.0_r17 only 1/6 lines present, fix not applied
• Android 16: not affected per bulletin (Android 16 not listed); at android-security-16.0.0_r8 only 1/6 lines present, fix not applied
• Android 17: same fix: commit 5819c807e810 in android-security-17.0.0_r1 (cherry-pick of 13872784a01e), 6/6 lines present

Unknowns

• Implementation of btm_sec_is_enc_algo_downgrade and the meaning of the two zero arguments.
• Whether the new check is actually gated by the aconfig flag named in the commit message (no flag check appears in the diff).
• Whether the fix was applied to the 16-qpr2 branch, which the bulletin/OSV lists as affected.
• What information is disclosed (bulletin type ID) and the exact remote trigger sequence beyond the commit message's description.

Back to September 2026 · Findings