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

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

[Radek Podgorny]

A bonded peer's connection parameters are stored under its identity
address, but hci_conn_params_lookup() matches only the exact address it
is given, so a caller holding the peer's RPA misses the entry.

hci_le_create_conn_sync() is such a caller: 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
connection is then created with the controller-wide defaults in hdev
instead of the peer's interval, latency and supervision timeout.

Resolve the RPA in hci_conn_params_lookup() when the exact match fails,
so every caller finds the same entry whichever of the peer's addresses
it holds. The exact match is tried first, so an entry stored under an
RPA is still found as before.

hci_conn_params_add() and hci_conn_params_del() look up through the
same function, so given a resolvable RPA they now act on the peer's
identity entry instead of creating or missing a separate one.

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>
---
Changes in v2:
- Resolve the RPA inside hci_conn_params_lookup() rather than at the
  hci_le_create_conn_sync() call site, as Luiz suggested, so no other
  caller can miss the entry
- Exact match still first, so entries stored under an RPA are unchanged.
  I weighed inlining this as one pass matching either address, but that
  lets list order rather than exactness decide between an RPA entry and
  an identity entry, and resolves the IRK on every RPA lookup; a small
  helper scanned twice seemed cleaner
- Rebased on bluetooth-next
- Link to v1: https://patch.msgid.link/20261101-for-upstream-le-conn-params-rpa-v1-1-988629a09bc9@podgorny.cz

Tested on the author's van (BCM4345C0 against a bonded peer that
rotates RPAs): with v2 the peer's stored connection parameters are used
again. bluetooth-next itself was only build-tested.

Per Documentation/process/generated-content.rst: the patch and this
message 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 and, for v2, to move the fix into
hci_conn_params_lookup() per review. The author directed the work,
reviewed the result and tested it on the van.
---
 net/bluetooth/hci_core.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bfc5bdebc71a2..2dc12c01c4dc1 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2285,9 +2285,8 @@ int hci_bdaddr_list_del_with_irk(struct list_head *list, bdaddr_t *bdaddr,
 	return 0;
 }
 
-/* This function requires the caller holds hdev->lock */
-struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
-					       bdaddr_t *addr, u8 addr_type)
+static struct hci_conn_params *conn_params_find(struct hci_dev *hdev,
+						bdaddr_t *addr, u8 addr_type)
 {
 	struct hci_conn_params *params;
 
@@ -2301,6 +2300,27 @@ struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
 	return NULL;
 }
 
+/* This function requires the caller holds hdev->lock */
+struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
+					       bdaddr_t *addr, u8 addr_type)
+{
+	struct hci_conn_params *params;
+	struct smp_irk *irk;
+
+	params = conn_params_find(hdev, addr, addr_type);
+	if (params)
+		return params;
+
+	/* A bonded peer's parameters are stored under its identity address,
+	 * so an RPA that resolves to it finds the same entry.
+	 */
+	irk = hci_get_irk(hdev, addr, addr_type);
+	if (!irk)
+		return NULL;
+
+	return conn_params_find(hdev, &irk->bdaddr, irk->addr_type);
+}
+
 /* This function requires the caller holds hdev->lock or rcu_read_lock */
 struct hci_conn_params *hci_pend_le_action_lookup(struct list_head *list,
 						  bdaddr_t *addr, u8 addr_type)

base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db
-- 
2.56.0

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

[Luiz Augusto von Dentz]

Hi Radek,

On Wed, Nov 4, 2026 at 7:07 AM Radek Podgorny <radek@podgorny.cz> wrote:
>
> A bonded peer's connection parameters are stored under its identity
> address, but hci_conn_params_lookup() matches only the exact address it
> is given, so a caller holding the peer's RPA misses the entry.
>
> hci_le_create_conn_sync() is such a caller: 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
> connection is then created with the controller-wide defaults in hdev
> instead of the peer's interval, latency and supervision timeout.
>
> Resolve the RPA in hci_conn_params_lookup() when the exact match fails,
> so every caller finds the same entry whichever of the peer's addresses
> it holds. The exact match is tried first, so an entry stored under an
> RPA is still found as before.
>
> hci_conn_params_add() and hci_conn_params_del() look up through the
> same function, so given a resolvable RPA they now act on the peer's
> identity entry instead of creating or missing a separate one.
>
> 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>
> ---
> Changes in v2:
> - Resolve the RPA inside hci_conn_params_lookup() rather than at the
>   hci_le_create_conn_sync() call site, as Luiz suggested, so no other
>   caller can miss the entry
> - Exact match still first, so entries stored under an RPA are unchanged.
>   I weighed inlining this as one pass matching either address, but that
>   lets list order rather than exactness decide between an RPA entry and
>   an identity entry, and resolves the IRK on every RPA lookup; a small
>   helper scanned twice seemed cleaner
> - Rebased on bluetooth-next
> - Link to v1: https://patch.msgid.link/20261101-for-upstream-le-conn-params-rpa-v1-1-988629a09bc9@podgorny.cz
>
> Tested on the author's van (BCM4345C0 against a bonded peer that
> rotates RPAs): with v2 the peer's stored connection parameters are used
> again. bluetooth-next itself was only build-tested.
>
> Per Documentation/process/generated-content.rst: the patch and this
> message 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 and, for v2, to move the fix into
> hci_conn_params_lookup() per review. The author directed the work,
> reviewed the result and tested it on the van.
> ---
>  net/bluetooth/hci_core.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index bfc5bdebc71a2..2dc12c01c4dc1 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2285,9 +2285,8 @@ int hci_bdaddr_list_del_with_irk(struct list_head *list, bdaddr_t *bdaddr,
>         return 0;
>  }
>
> -/* This function requires the caller holds hdev->lock */
> -struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
> -                                              bdaddr_t *addr, u8 addr_type)
> +static struct hci_conn_params *conn_params_find(struct hci_dev *hdev,
> +                                               bdaddr_t *addr, u8 addr_type)
>  {
>         struct hci_conn_params *params;
>
> @@ -2301,6 +2300,27 @@ struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
>         return NULL;
>  }
>
> +/* This function requires the caller holds hdev->lock */
> +struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
> +                                              bdaddr_t *addr, u8 addr_type)
> +{
> +       struct hci_conn_params *params;
> +       struct smp_irk *irk;
> +
> +       params = conn_params_find(hdev, addr, addr_type);
> +       if (params)
> +               return params;
> +
> +       /* A bonded peer's parameters are stored under its identity address,
> +        * so an RPA that resolves to it finds the same entry.
> +        */
> +       irk = hci_get_irk(hdev, addr, addr_type);
> +       if (!irk)
> +               return NULL;
> +
> +       return conn_params_find(hdev, &irk->bdaddr, irk->addr_type);
> +}
> +
>  /* This function requires the caller holds hdev->lock or rcu_read_lock */
>  struct hci_conn_params *hci_pend_le_action_lookup(struct list_head *list,
>                                                   bdaddr_t *addr, u8 addr_type)
>
> base-commit: 3f425f95ba3923d605f6a8b382e8fcdc59d479db
> --
> 2.56.0

Sashiko flagged quite a few issues, please have a look and lets
resolve them before merging:
https://sashiko.dev/#/patchset/20261104120138.1165715-1-radek%40podgorny.cz

-- 
Luiz Augusto von Dentz

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

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 4096 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/1201734/

---Test result---

Test Summary:
CheckPatch                    FAIL      2.03 seconds
VerifyFixes                   PASS      10.78 seconds
VerifySignedoff               PASS      0.87 seconds
GitLint                       PASS      0.37 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      21.93 seconds
CheckAllWarning               PASS      24.10 seconds
CheckSparse                   PASS      39.62 seconds
BuildKernel32                 PASS      26.36 seconds
CheckKernelLLVM               PASS      21.52 seconds
TestRunnerSetup               PASS      480.51 seconds
TestRunner_l2cap-tester       FAIL      11.88 seconds
TestRunner_iso-tester         PASS      13.53 seconds
TestRunner_bnep-tester        PASS      2.97 seconds
TestRunner_mgmt-tester        PASS      83.68 seconds
TestRunner_rfcomm-tester      PASS      4.10 seconds
TestRunner_sco-tester         PASS      5.26 seconds
TestRunner_ioctl-tester       PASS      9.60 seconds
TestRunner_mesh-tester        PASS      12.86 seconds
TestRunner_smp-tester         PASS      7.67 seconds
TestRunner_userchan-tester    PASS      4.06 seconds
TestRunner_6lowpan-tester     PASS      4.51 seconds
IncrementalBuild              PASS      20.54 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v2] Bluetooth: find an RPA peer's connection parameters by its identity
WARNING: Non-standard signature: Assisted-by:
#82: 
Assisted-by: Claude:claude-opus-5-5

ERROR: Unrecognized email address: 'Claude:claude-opus-5-5'
#82: 
Assisted-by: Claude:claude-opus-5-5

total: 1 errors, 1 warnings, 0 checks, 38 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

/home/runner/work/bluetooth-next/bluetooth-next/src/patch/14943961.patch has style problems, please review.

NOTE: Ignored message types: UNKNOWN_COMMIT_ID

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.


##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Sanitizer errors:
==37==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c0d93ce33d0 at pc 0x564f5dac9e8e bp 0x7ffe8f53d490 sp 0x7ffe8f53d480
READ of size 4 at 0x7c0d93ce33d0 thread T0
    #0 0x564f5dac9e8d in timeout_callback src/shared/timeout-mainloop.c:33
    #1 0x564f5dacab75 in timeout_callback src/shared/mainloop.c:270
    #2 0x564f5dacbaa6 in mainloop_run src/shared/mainloop.c:124
    #3 0x564f5dace3fa in mainloop_run_with_signal src/shared/mainloop-notify.c:196
    #4 0x564f5dad364b in tester_run src/shared/tester.c:1223
    #5 0x564f5d9fd17d in main tools/l2cap-tester.c:3918
    #6 0x7fcd94c80600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
    #7 0x7fcd94c80717 in __libc_start_main_impl ../csu/libc-start.c:360
    #8 0x564f5da03c84 in _start (/home/runner/work/bluetooth-next/bluetooth-next/src/bluez/tools/l2cap-tester+0x16cc84) (BuildId: 91c9d49e9766c394468e27ffa29b05e7d348169f)

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

previously allocated by thread T0 here:
    #0 0x7fcd955bf60f in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x564f5dab42d5 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/1063

---
Regards,
Linux Bluetooth