CVE-2025-0092 AI-generated analysis

platform/packages/modules/Bluetooth, btservice (BondStateMachine / AdapterService bond-state handling; affects MAP, PBAP and SAP access permissions)

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

The fix resets a remote device's Message Access, Phonebook Access and SIM Access permissions to ACCESS_UNKNOWN whenever its bond state transitions to BOND_NONE, so that access granted while a device was bonded does not survive unbonding.

Root cause

In BondStateMachine's bond-state intent path (sendIntent, per the in-file comment), when a device's bond state changed to BOND_NONE, the code broadcast ACTION_BOND_STATE_CHANGED and notified AdapterService. It never cleared the per-device message, phonebook and SIM access permission values held by AdapterService, so those permissions persisted for a device that was no longer bonded. The commit message cites two spec requirements: PBAP requires the user to confirm at least the first PBAP connection from each new PCE, and MAP requires the MCE and MSE to be bonded before a MAP connection is set up.

How the fix works

• android/app/src/com/android/bluetooth/btservice/BondStateMachine.java:sendIntent (Android 14): the fix adds an `if (newState == BluetoothDevice.BOND_NONE)` block after the pending-SDP handling block and before the ACTION_BOND_STATE_CHANGED intent is built. The block calls mAdapterService.setMessageAccessPermission, setPhonebookAccessPermission and setSimAccessPermission with BluetoothDevice.ACCESS_UNKNOWN for the device.
• The new block sits before mAdapterService.onBondStateChanged(device, newState) and before the broadcast, so the permissions are already reset when those run.
• Android 15 (090ca53cc13c): the same three reset calls are placed in AdapterService.java instead, in the bond-state handling method that calls mDatabaseManager.handleBondStateChanged(device, fromState, toState). They are guarded by `toState == BOND_NONE`, and the commit adds a static import of BluetoothDevice.BOND_NONE.

Completeness

• The fix covers all three per-device access permissions (message, phonebook, SIM). It covers every transition to BOND_NONE that goes through this BondStateMachine path, whatever the old state, so it includes failed pairings (BONDING -> NONE) and explicit unbonds (BONDED -> NONE).
• The reset only happens on a transition event. The diff contains no one-time cleanup of permissions already stored for devices that were unbonded before the fix was installed.
• On Android 14 the hook is inside BondStateMachine.sendIntent, so a bond-state change that bypasses this path would not trigger the reset; the material shows no such path. Android 15 places the hook in AdapterService instead.

Behavior changes

• After a device is unbonded or a pairing attempt fails, its MAP, PBAP and SAP access permissions are set to ACCESS_UNKNOWN.
• Three additional set*AccessPermission calls run on every BOND_NONE transition, before the ACTION_BOND_STATE_CHANGED broadcast (Android 14).

Per major

• Android 14: same fix: 142acc56658c in android-security-14.0.0_r17 adds the BOND_NONE reset block in BondStateMachine.sendIntent; 3/3 patched lines present at android-security-14.0.0_r29.
• Android 15: adapted fix: 090ca53cc13c in android-security-15.0.0_r5 places the same three reset calls in AdapterService (toState == BOND_NONE) and adds a BOND_NONE static import; 8/8 lines present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin); the patched region is present (3/3) at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin); the patched region is present (3/3) at android-security-17.0.0_r1.

Unknowns

• Whether the set*AccessPermission values are persisted across reboots, and whether stale pre-fix entries are cleaned up elsewhere; the material shows no such cleanup.
• The exact MAP/PBAP/SAP connection-acceptance code that used the stale permission; only the spec requirements quoted in the commit message are provided.
• Whether the Android 15 hook method is named handleBondStateChanged; the diff hunk header shows only the class, not the enclosing method.
• The Android 14 enclosing method name sendIntent is inferred from an in-file comment; the code excerpt does not show the method signature.
• Whether ag/30386015 corresponds to the Android 15 commit 090ca53cc13c.

Back to March 2025 · Findings