fix(nordic): remove 2M PHY udpate request
What changed, and why it matters
This commit disables a request that tells nearby Bluetooth Low Energy devices to use a faster 2 Mbps radio mode ('2M PHY') right after a connection is established. The change is presented as a fix for Nordic hardware, but the commit message gives no security explanation. It may be a stability or compatibility workaround rather than a security patch.
Treat this as a normal firmware fix unless a vendor security advisory or independent analysis links the 2M PHY request to a concrete Bluetooth attack. Users should keep firmware updated through normal channels. If security review is required, investigate whether forced 2M PHY could enable range-reduction, PHY-based side channels, or host compatibility issues that affect pairing integrity.
Security signals we found
Bluetooth LE PHY preference changed from 2M to default/legacy 1M
Commit title frames change as a 'fix' but does not claim security relevance
No changelog entry provided, reducing transparency
No CVE, advisory, or researcher attribution in commit or supplied references
Evidence from the diff
In the Trezor firmware’s Nordic Bluetooth LE stack, the connected() callback previously called bt_conn_le_phy_update() to request the 2M LE PHY immediately after connection. The patch comments out that PHY update request. The 2M PHY has shorter range and different timing than the default 1M PHY; forcing it on every connection could cause interoperability, range, or timing issues on some hosts. There is no direct evidence in the diff or message that this is a security fix, nor is there a clear vulnerability being closed.
Changed components
nordic/trezor/trezor-ble/src/ble/connection.cTrezor BLE connection setup on Nordic nRF-based hardwareInspect captured patch +7 / −7
diff --git a/nordic/trezor/trezor-ble/src/ble/connection.c b/nordic/trezor/trezor-ble/src/ble/connection.c
index 6b13c534d..8debe85f2 100644
--- a/nordic/trezor/trezor-ble/src/ble/connection.c
+++ b/nordic/trezor/trezor-ble/src/ble/connection.c
@@ -70,13 +70,13 @@ void connected(struct bt_conn *conn, uint8_t err) {
bt_conn_le_param_update(conn, param);
// Prefer 2M both directions; 0 options = no specific constraints
- const struct bt_conn_le_phy_param phy_2m = {
- .options = 0,
- .pref_tx_phy = BT_GAP_LE_PHY_2M,
- .pref_rx_phy = BT_GAP_LE_PHY_2M,
- };
-
- bt_conn_le_phy_update(conn, &phy_2m);
+ // const struct bt_conn_le_phy_param phy_2m = {
+ // .options = 0,
+ // .pref_tx_phy = BT_GAP_LE_PHY_2M,
+ // .pref_rx_phy = BT_GAP_LE_PHY_2M,
+ //};
+ //
+ // bt_conn_le_phy_update(conn, &phy_2m);
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
LOG_INF("Connected %s", addr);
Why this scored 22/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.