Re: [PATCH BlueZ 0/2] Don't auto-bond on reactive GATT security elevation

Hi Philipp,

On Sat, Jul 18, 2026 at 3:43 PM Philipp Dunkel <[email protected]> wrote:
>
> bluetoothd probes every freshly connected LE peer as a GATT client
> through its built-in profiles (battery, mcp, ...). When such a probe
> reads a characteristic the peer has protected, the peer answers with
> Insufficient Authentication (0x05), and change_security() reacts by
> raising BT_SECURITY on the ATT socket. On an unbonded LE link that
> starts SMP pairing, so the user is shown a pairing prompt for a device
> that merely came into range -- a bond nobody requested, logged as a
> device_bonding_complete() bond with a (nil) requestor.

You will need to determine which plugins are discovering attributes
that may require encryption and disable them since they won't function
otherwise and are probably just dead weight at that point. Also I
don't think there is an easy policy to determine the roles of each
side since "client" doesn't necessarily mean central, nor does
peripheral necessarily mean server.

> The existing opt-out does not help: change_security() only bails when
> chan->sec_level != BT_ATT_SECURITY_AUTO, but sec_level is recorded for
> BT_ATT_LOCAL channels only, so an L2CAP/LE channel stays at AUTO for its
> whole lifetime and always elevates.
>
> Patch 1 adds bt_att_set_no_auto_sec(), a per-bt_att flag that makes
> change_security() refuse to elevate, and sets it from gatt_client_init()
> for any link that is neither bonded nor in a requested bonding.
> In-progress Pair() and already-bonded devices keep their existing
> elevation paths untouched.
>
> Patch 2 adds a unit test: it arms AUTO security and then forbids
> elevation, asserting the auth error is delivered to the caller with no
> retry on the wire. Without patch 1 the client retries and the test
> aborts on the unexpected Read Request.
>
> Tested against Android (Galaxy Z Flip 4), iOS (iPhone) and macOS
> (MacBook): each connects and is probed with no unsolicited pairing
> prompt, while explicit pairing continues to work.

Why are you connecting in the first place? Who is advertising?
Actually if you end up with an encrypted link, that's a win in terms
of security, so why would it be a bad thing?

> Both patches were developed with the assistance of an AI model
> (Claude Opus 4.8), disclosed per-patch with an Assisted-by: trailer.
> Every line was reviewed by me and the result was built, run and tested
> on the hardware above -- behaviour observed, not inferred.
>
> Philipp Dunkel (2):
>   shared/att: don't auto-bond on reactive elevation
>   unit/test-gatt: cover no-auto-sec on auth error
>
>  src/device.c     | 13 +++++++++++++
>  src/shared/att.c | 20 ++++++++++++++++++++
>  src/shared/att.h |  1 +
>  unit/test-gatt.c | 28 ++++++++++++++++++++++++++++
>  4 files changed, 62 insertions(+)
>
> --
> 2.55.0
>
>


-- 
Luiz Augusto von Dentz