7.2.y took the on-air address fix without its companion

7.2.y took the on-air address fix without its companion

[Radek Podgorny]

Hi Luiz, Marcel,

7.2.8 picked up, via AUTOSEL,

  a552b4bc058b Bluetooth: put the peer's on-air address on air when we
               cannot resolve        (mainline 4914c4998961)

but not the patch that was sent and merged immediately before it:

  14b015afb556 Bluetooth: forget a peer's RPA once it advertises its
               identity address      (bluetooth-next only)

They went out as a two-patch series because the second one depends on
the first, and the commit message now in 7.2.8 says so itself:

  Without that, a peer that turns privacy off would be dialled on the
  address it abandoned rather than the one it is answering on.

That is the situation in 7.2.y now, and it is a regression against
7.2.6:

 - hci_connect_le() substitutes the cached irk->rpa for the identity
   address whenever the IRK has one.
 - __hci_conn_add() in 7.2.8 keeps that RPA when LL Privacy resolution
   is off or the peer is not in the resolving list, which is the change
   a552b4bc058b makes.
 - Nothing in 7.2.8 ever clears irk->rpa. The only writes to it install
   a newer RPA, in hci_find_irk_by_rpa() and hci_add_irk().

So a bonded peer that stops using RPAs and advertises its identity
address is dialled forever on an address it no longer answers on. In
7.2.6 __hci_conn_add() converted the address unconditionally, so the
same peer was dialled on its identity and the connection succeeded.

14b015afb556 is the invalidation that closes this: it clears irk->rpa
in process_adv_report() once the peer is seen advertising its identity
address. Nine added lines in one file.

Could it go to mainline as a fix during the 7.3 cycle rather than
waiting for the 7.4 merge window? Once it is upstream it reaches 7.2.y
by the normal route. I deliberately left a Fixes: tag off it when it
was posted, so as not to invite a backport while __hci_conn_add() was
still masking the stale address -- that reasoning does not hold any
more now that a552b4bc058b is in a released stable kernel. I am glad to
repost it with Cc: stable@vger.kernel.org if you would rather have it
that way.

For the stable team: if holding it is not workable, reverting
a552b4bc058b from 7.2.y restores the 7.2.6 behaviour, at the cost of
re-exposing the bug that patch fixes. Only 7.2.y is affected; 6.18.54,
6.12.111 and 6.6.157 carry neither patch.

Both have been running together here since September. 7.2.8 is the
first kernel I have seen with only the second half.

Thanks,
Radek Podgorny

Re: 7.2.y took the on-air address fix without its companion

[Greg Kroah-Hartman]

On Fri, Oct 02, 2026 at 11:45:45PM +0200, Radek Podgorny wrote:
> Hi Luiz, Marcel,
> 
> 7.2.8 picked up, via AUTOSEL,
> 
>   a552b4bc058b Bluetooth: put the peer's on-air address on air when we
>                cannot resolve        (mainline 4914c4998961)
> 
> but not the patch that was sent and merged immediately before it:
> 
>   14b015afb556 Bluetooth: forget a peer's RPA once it advertises its
>                identity address      (bluetooth-next only)

There is no such commit id in Linus's tree :(

> They went out as a two-patch series because the second one depends on
> the first, and the commit message now in 7.2.8 says so itself:
> 
>   Without that, a peer that turns privacy off would be dialled on the
>   address it abandoned rather than the one it is answering on.
> 
> That is the situation in 7.2.y now, and it is a regression against
> 7.2.6:
> 
>  - hci_connect_le() substitutes the cached irk->rpa for the identity
>    address whenever the IRK has one.
>  - __hci_conn_add() in 7.2.8 keeps that RPA when LL Privacy resolution
>    is off or the peer is not in the resolving list, which is the change
>    a552b4bc058b makes.
>  - Nothing in 7.2.8 ever clears irk->rpa. The only writes to it install
>    a newer RPA, in hci_find_irk_by_rpa() and hci_add_irk().
> 
> So a bonded peer that stops using RPAs and advertises its identity
> address is dialled forever on an address it no longer answers on. In
> 7.2.6 __hci_conn_add() converted the address unconditionally, so the
> same peer was dialled on its identity and the connection succeeded.
> 
> 14b015afb556 is the invalidation that closes this: it clears irk->rpa
> in process_adv_report() once the peer is seen advertising its identity
> address. Nine added lines in one file.
> 
> Could it go to mainline as a fix during the 7.3 cycle rather than
> waiting for the 7.4 merge window? Once it is upstream it reaches 7.2.y
> by the normal route. I deliberately left a Fixes: tag off it when it
> was posted, so as not to invite a backport while __hci_conn_add() was
> still masking the stale address -- that reasoning does not hold any
> more now that a552b4bc058b is in a released stable kernel. I am glad to
> repost it with Cc: stable@vger.kernel.org if you would rather have it
> that way.
> 
> For the stable team: if holding it is not workable, reverting
> a552b4bc058b from 7.2.y restores the 7.2.6 behaviour, at the cost of
> re-exposing the bug that patch fixes. Only 7.2.y is affected; 6.18.54,
> 6.12.111 and 6.6.157 carry neither patch.

I'll wait for this to hit Linus's tree before pulling it into the stable
releases.  Please let us know when that happens.

thanks,

greg k-h