fix(core): increase bonds count immediately after receiving pairing completed message
What the developer wrote
Authored by tychovrahe
fix(core): increase bonds count immediately after receiving pairing completed message
[no changelog]
What changed, and why it matters
This commit fixes a bookkeeping bug in the Bluetooth pairing code of Trezor hardware wallets. The device now correctly increments its count of bonded peers immediately when it receives confirmation that pairing completed. Previously, the count may have been updated late or missed, which could cause the wallet to incorrectly think it had no bonded Bluetooth devices or to allow more pairings than intended. The change is small and defensive, but the exact security consequences depend on how the stale count was used elsewhere in the firmware.
Review all consumers of drv->peer_count and the bond-count limit logic to confirm the counter is now authoritative and cannot be manipulated through repeated pairing/unpairing sequences. Consider adding defensive checks that compare peer_count against the controller's actual bond list. Because the commit is marked [no changelog], verify whether a security advisory or changelog entry is warranted once the full impact is assessed.
Security signals we found
State desynchronization between BLE controller bond list and firmware peer_count
Missing increment on pairing-completed event
Potential bypass of bond-count limits if peer_count is used for access control
Bluetooth/BLE attack surface in hardware wallet
[no changelog] marker present in commit message
Evidence from the diff
In core/embed/io/ble/stm32/ble.c, ble_process_rx_msg_pairing_completed() now increments drv->peer_count when the BLE stack reports a successful pairing. This brings the in-memory bond counter in line with the actual bonded-peer state maintained by the BLE controller. A desynchronized peer_count could affect logic that limits the number of bonded devices, decides whether to allow new pairings, or reports bond status to the host/application. The patch is one line and does not include other hardening, so it should be viewed as a partial fix to a state-synchronization issue rather than a complete security boundary change.
Changed components
core/embed/io/ble/stm32/ble.cTrezor Core BLE driverBluetooth pairing/bonding state machineInspect captured patch +1 / −0
diff --git a/core/embed/io/ble/stm32/ble.c b/core/embed/io/ble/stm32/ble.c
index d9cb9d7d4..1a1611c08 100644
--- a/core/embed/io/ble/stm32/ble.c
+++ b/core/embed/io/ble/stm32/ble.c
@@ -404,6 +404,7 @@ static void ble_process_rx_msg_pairing_completed(const uint8_t *data,
tsqueue_enqueue(&drv->event_queue, (uint8_t *)&event, sizeof(event), NULL);
drv->pairing_allowed = false;
drv->pairing_requested = false;
+ drv->peer_count += 1;
}
static void ble_process_rx_msg_mac(const uint8_t *data, uint32_t len) {
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.