[PATCH] Bluetooth: find an RPA peer's connection parameters by its identity

[PATCH] Bluetooth: find an RPA peer's connection parameters by its identity

[Radek Podgorny]

hci_le_create_conn_sync() looks up the peer's connection parameters by
conn->dst. Those parameters are stored under the identity address, but
hci_connect_le() puts the peer's cached RPA in conn->dst, and
__hci_conn_add() no longer converts it back when the controller cannot
translate an identity address.

The lookup then misses, and the connection is created with the
controller-wide defaults in hdev instead of the peer's interval, latency
and supervision timeout.

Resolve an RPA to its identity before the lookup, as
hci_connect_le_scan_cleanup() does. The other lookups by conn->dst run
after le_conn_complete_evt() has resolved it, so they are not affected.

Measured with btmon on a BCM4345C0 against a bonded peer that rotates
RPAs, with stored parameters of interval 12, latency 0 and timeout 600,
over six forced reconnects each way on v7.3.1:

                       before          after
  requested interval   30.00-50.00 ms  15.00-15.00 ms
  requested timeout    420 ms          6000 ms
  link interval        48.75 ms        15.00 ms
  link timeout         420 ms          6000 ms

Fixes: 4914c4998961 ("Bluetooth: put the peer's on-air address on air when we cannot resolve")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Radek Podgorny <radek@podgorny.cz>
---
This is the follow-up to the on-air address patch that Luiz said could
be done on top:
https://lore.kernel.org/linux-bluetooth/CABBYNZ+5zV8xzhHZKTUQYT4tLHaZAO7iiKOEsKuT8aA+YNLjPQ@mail.gmail.com/

What this does not establish:
 - tested on v7.3.1, not on bluetooth-next; the patch applies to both
   and bluetooth-next was only build-tested
 - it shows the stored parameters now reach the controller. It does not
   show that links are more reliable: all twelve reconnects succeeded,
   with or without the patch

Per Documentation/process/generated-content.rst: the patch, this message
and the btmon test runs were done with the Claude coding assistant
(model as in the Assisted-by trailer). The prompts asked it to fix the
lookup miss named in the on-air address review, then to measure the
result on the author's van, with and without the patch. The author
directed the work and reviewed the result.
---
 net/bluetooth/hci_sync.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 9d829c20c31604..810d6f5143342a 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -7018,6 +7018,7 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
 {
 	struct hci_cp_le_create_conn cp;
 	struct hci_conn_params *params;
+	struct smp_irk *irk;
 	u8 own_addr_type;
 	int err;
 	struct hci_conn *conn = data;
@@ -7057,7 +7058,16 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
 
 	hci_dev_lock(hdev);
 
-	params = hci_conn_params_lookup(hdev, &conn->dst, conn->dst_type);
+	/* conn->dst may hold the peer's RPA, but connection parameters are
+	 * stored under its identity address.
+	 */
+	irk = hci_get_irk(hdev, &conn->dst, conn->dst_type);
+	if (irk)
+		params = hci_conn_params_lookup(hdev, &irk->bdaddr,
+						irk->addr_type);
+	else
+		params = hci_conn_params_lookup(hdev, &conn->dst,
+						conn->dst_type);
 	if (params) {
 		conn->le_conn_min_interval = params->conn_min_interval;
 		conn->le_conn_max_interval = params->conn_max_interval;

---
base-commit: 42b8c2d729268a65a2d98064e8dc59ff53646b14
change-id: 20261101-for-upstream-le-conn-params-rpa-f2334fb5dda7

-- 
Radek Podgorny <radek@podgorny.cz>

RE: Bluetooth: find an RPA peer's connection parameters by its identity

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1198202/

---Test result---

Test Summary:
CheckPatch                    PASS      3.92 seconds
VerifyFixes                   PASS      1.28 seconds
VerifySignedoff               PASS      0.11 seconds
GitLint                       PASS      0.31 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      28.99 seconds
CheckAllWarning               PASS      33.23 seconds
CheckSparse                   PASS      35.53 seconds
BuildKernel32                 PASS      29.33 seconds
CheckKernelLLVM               PASS      31.75 seconds
TestRunnerSetup               PASS      678.99 seconds
TestRunner_l2cap-tester       FAIL      12.14 seconds
TestRunner_iso-tester         PASS      10.45 seconds
TestRunner_bnep-tester        PASS      2.99 seconds
TestRunner_mgmt-tester        PASS      86.50 seconds
TestRunner_rfcomm-tester      PASS      4.29 seconds
TestRunner_sco-tester         PASS      5.38 seconds
TestRunner_ioctl-tester       PASS      4.50 seconds
TestRunner_mesh-tester        PASS      5.32 seconds
TestRunner_smp-tester         PASS      4.17 seconds
TestRunner_userchan-tester    PASS      3.06 seconds
TestRunner_6lowpan-tester     PASS      4.24 seconds
IncrementalBuild              PASS      27.60 seconds

Details
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Sanitizer errors:
==36==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b926a3e33d0 at pc 0x556ffff58e8e bp 0x7ffc6f1889b0 sp 0x7ffc6f1889a0
READ of size 4 at 0x7b926a3e33d0 thread T0
    #0 0x556ffff58e8d in timeout_callback src/shared/timeout-mainloop.c:33
    #1 0x556ffff59b75 in timeout_callback src/shared/mainloop.c:270
    #2 0x556ffff5aaa6 in mainloop_run src/shared/mainloop.c:124
    #3 0x556ffff5d3fa in mainloop_run_with_signal src/shared/mainloop-notify.c:196
    #4 0x556ffff6264b in tester_run src/shared/tester.c:1223
    #5 0x556fffe8c17d in main tools/l2cap-tester.c:3918
    #6 0x7f526b350600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
    #7 0x7f526b350717 in __libc_start_main_impl ../csu/libc-start.c:360
    #8 0x556fffe92c84 in _start (/home/runner/work/bluetooth-next/bluetooth-next/src/bluez/tools/l2cap-tester+0x16cc84) (BuildId: 91c9d49e9766c394468e27ffa29b05e7d348169f)

0x7b926a3e33d0 is located 0 bytes inside of 40-byte region [0x7b926a3e33d0,0x7b926a3e33f8)
freed by thread T0 here:
    #0 0x7f526bc8e3ff in free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:51
    #1 0x556ffff5936a in timeout_destroy src/shared/mainloop.c:251

previously allocated by thread T0 here:
    #0 0x7f526bc8f60f in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x556ffff432d5 in util_malloc src/shared/util.c:46

SUMMARY: AddressSanitizer: heap-use-after-free src/shared/timeout-mainloop.c:33 in timeout_callback
No test result found


https://github.com/bluez/bluetooth-next/pull/1037

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: find an RPA peer's connection parameters by its identity

[Luiz Augusto von Dentz]

Hi Radek,

On Sun, Nov 1, 2026 at 12:20 PM Radek Podgorny <radek@podgorny.cz> wrote:
>
> hci_le_create_conn_sync() looks up the peer's connection parameters by
> conn->dst. Those parameters are stored under the identity address, but
> hci_connect_le() puts the peer's cached RPA in conn->dst, and
> __hci_conn_add() no longer converts it back when the controller cannot
> translate an identity address.
>
> The lookup then misses, and the connection is created with the
> controller-wide defaults in hdev instead of the peer's interval, latency
> and supervision timeout.
>
> Resolve an RPA to its identity before the lookup, as
> hci_connect_le_scan_cleanup() does. The other lookups by conn->dst run
> after le_conn_complete_evt() has resolved it, so they are not affected.
>
> Measured with btmon on a BCM4345C0 against a bonded peer that rotates
> RPAs, with stored parameters of interval 12, latency 0 and timeout 600,
> over six forced reconnects each way on v7.3.1:
>
>                        before          after
>   requested interval   30.00-50.00 ms  15.00-15.00 ms
>   requested timeout    420 ms          6000 ms
>   link interval        48.75 ms        15.00 ms
>   link timeout         420 ms          6000 ms
>
> Fixes: 4914c4998961 ("Bluetooth: put the peer's on-air address on air when we cannot resolve")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Radek Podgorny <radek@podgorny.cz>
> ---
> This is the follow-up to the on-air address patch that Luiz said could
> be done on top:
> https://lore.kernel.org/linux-bluetooth/CABBYNZ+5zV8xzhHZKTUQYT4tLHaZAO7iiKOEsKuT8aA+YNLjPQ@mail.gmail.com/
>
> What this does not establish:
>  - tested on v7.3.1, not on bluetooth-next; the patch applies to both
>    and bluetooth-next was only build-tested
>  - it shows the stored parameters now reach the controller. It does not
>    show that links are more reliable: all twelve reconnects succeeded,
>    with or without the patch
>
> Per Documentation/process/generated-content.rst: the patch, this message
> and the btmon test runs were done with the Claude coding assistant
> (model as in the Assisted-by trailer). The prompts asked it to fix the
> lookup miss named in the on-air address review, then to measure the
> result on the author's van, with and without the patch. The author
> directed the work and reviewed the result.
> ---
>  net/bluetooth/hci_sync.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index 9d829c20c31604..810d6f5143342a 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -7018,6 +7018,7 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
>  {
>         struct hci_cp_le_create_conn cp;
>         struct hci_conn_params *params;
> +       struct smp_irk *irk;
>         u8 own_addr_type;
>         int err;
>         struct hci_conn *conn = data;
> @@ -7057,7 +7058,16 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
>
>         hci_dev_lock(hdev);
>
> -       params = hci_conn_params_lookup(hdev, &conn->dst, conn->dst_type);
> +       /* conn->dst may hold the peer's RPA, but connection parameters are
> +        * stored under its identity address.
> +        */
> +       irk = hci_get_irk(hdev, &conn->dst, conn->dst_type);
> +       if (irk)
> +               params = hci_conn_params_lookup(hdev, &irk->bdaddr,
> +                                               irk->addr_type);
> +       else
> +               params = hci_conn_params_lookup(hdev, &conn->dst,
> +                                               conn->dst_type);

I guess this could be incorporated to hci_conn_params_lookup
internally, so we don't risk other part of the code missing the params
and any address used, RPA or not, should resolve to the same entry.

>         if (params) {
>                 conn->le_conn_min_interval = params->conn_min_interval;
>                 conn->le_conn_max_interval = params->conn_max_interval;
>
> ---
> base-commit: 42b8c2d729268a65a2d98064e8dc59ff53646b14
> change-id: 20261101-for-upstream-le-conn-params-rpa-f2334fb5dda7
>
> --
> Radek Podgorny <radek@podgorny.cz>
>


-- 
Luiz Augusto von Dentz