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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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