[PATCH] Bluetooth: hci_sync: Use the advertising set handle, not the instance

[PATCH] Bluetooth: hci_sync: Use the advertising set handle, not the instance

[Weihong Guan]

When the controller supports a single advertising set,
hci_add_adv_instance() gives instance 1 handle 0x00. The parameters,
data and enable commands for an instance use adv->handle, but two
commands still send the instance number as the advertising handle:

 - LE Set Advertising Set Random Address, from
   hci_set_adv_set_random_addr_sync(). The random address goes to
   handle 0x01, a set the controller doesn't have, and an instance
   using a random address, such as a non-connectable one, never
   starts:

     $ btmgmt add-adv -d 0A09434841445654455354 1
     Add Advertising failed with status 0x0d (Invalid Parameters)

     < HCI Command: LE Set Extended Advertising Parameters  Handle: 0x00
     < HCI Command: LE Set Extended Advertising Data        Handle: 0x00
     < HCI Command: LE Set Advertising Set Random Address
           Advertising handle: 0x01

 - LE Remove Advertising Set, from hci_remove_ext_adv_instance_sync(),
   so removing instance 1 fails with Unknown Advertising Identifier:

     $ btmgmt rm-adv 1
     Remove Advertising failed with status 0x03 (Failed)

     < HCI Command: LE Remove Advertising Set  Handle: 1
     > HCI Event: Command Complete
           Status: Unknown Advertising Identifier (0x42)

Look the instance up and use its handle, as the other set commands do.
In hci_set_adv_set_random_addr_sync() the instance stays the function's
argument, so instance 0 still updates hdev->random_addr, which is shared
with scanning.

Fixes: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
Assisted-by: Claude:claude-opus-5.5
Signed-off-by: Weihong Guan <weihong.guan@gmail.com>
---
Notes, outside the commit:

Tested on a Raspberry Pi 5 with its 6.18.50 kernel, with this change and
a local equivalent of 1bfecdbd03 ("Bluetooth: HCI: Fix tracking of
instances sharing handle 0x00"), which depends on changes 6.18 doesn't
have. The controller is an open link layer on a WCH CH583 behind HCI
over USB, reporting one advertising set. Non-connectable and connectable
instances are added and removed with btmgmt, every advertising command
on handle 0x00 and answered Success. That kernel has also run our BLE test
suite through BlueZ since. Build-tested on bluetooth-next with W=1, no
new warnings.

Two related spots I've left alone, as the ownership of handle 0x00 is
better judged by you:

 - hci_cc_le_set_adv_set_random_addr() returns early for handle 0x00
   and otherwise looks the set up by instance number, so a single-set
   controller's instance 1 never gets adv->random_addr recorded. A
   by-handle lookup there may meet hdev->cur_adv_instance before it is
   updated for the instance being set up.
 - hci_le_ext_adv_term_evt() looks up ev->handle as an instance and
   stores it as conn->adv_instance.

Also, removing a single-set controller's instance 1 now removes set
0x00, which Global Advertising also uses; if you'd rather disable than
remove there, I'm happy to rework it.

 net/bluetooth/hci_sync.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index c9e80b957..cdd175fe5 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -1248,6 +1248,7 @@ static int hci_set_adv_set_random_addr_sync(struct hci_dev *hdev, u8 instance,
 					    bdaddr_t *random_addr)
 {
 	struct hci_cp_le_set_adv_set_rand_addr cp;
+	struct adv_info *adv = NULL;
 	int err;
 
 	if (!instance) {
@@ -1261,9 +1262,12 @@ static int hci_set_adv_set_random_addr_sync(struct hci_dev *hdev, u8 instance,
 			return err;
 	}
 
+	if (instance)
+		adv = hci_find_adv_instance(hdev, instance);
+
 	memset(&cp, 0, sizeof(cp));
 
-	cp.handle = instance;
+	cp.handle = adv ? adv->handle : instance;
 	bacpy(&cp.bdaddr, random_addr);
 
 	return __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_ADV_SET_RAND_ADDR,
@@ -2067,6 +2071,8 @@ int hci_enable_advertising(struct hci_dev *hdev)
 int hci_remove_ext_adv_instance_sync(struct hci_dev *hdev, u8 instance,
 				     struct sock *sk)
 {
+	struct adv_info *adv = NULL;
+	u8 handle;
 	int err;
 
 	if (!ext_adv_capable(hdev))
@@ -2077,11 +2083,16 @@ int hci_remove_ext_adv_instance_sync(struct hci_dev *hdev, u8 instance,
 		return err;
 
 	/* If request specifies an instance that doesn't exist, fail */
-	if (instance > 0 && !hci_find_adv_instance(hdev, instance))
-		return -EINVAL;
+	if (instance > 0) {
+		adv = hci_find_adv_instance(hdev, instance);
+		if (!adv)
+			return -EINVAL;
+	}
+
+	handle = adv ? adv->handle : instance;
 
 	return __hci_cmd_sync_status_sk(hdev, HCI_OP_LE_REMOVE_ADV_SET,
-					sizeof(instance), &instance, 0,
+					sizeof(handle), &handle, 0,
 					HCI_CMD_TIMEOUT, sk);
 }
 
-- 
2.47.3

RE: Bluetooth: hci_sync: Use the advertising set handle, not the instance

[bluez.test.bot]

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

---Test result---

Test Summary:
CheckPatch                    PASS      0.61 seconds
VerifyFixes                   PASS      0.07 seconds
VerifySignedoff               PASS      0.07 seconds
GitLint                       PASS      1.15 seconds
SubjectPrefix                 PASS      0.07 seconds
BuildKernel                   PASS      29.22 seconds
CheckAllWarning               PASS      33.94 seconds
CheckSparse                   PASS      36.52 seconds
BuildKernel32                 PASS      30.53 seconds
CheckKernelLLVM               PASS      35.05 seconds
TestRunnerSetup               PASS      705.10 seconds
TestRunner_l2cap-tester       PASS      12.84 seconds
TestRunner_iso-tester         PASS      10.63 seconds
TestRunner_bnep-tester        PASS      3.08 seconds
TestRunner_mgmt-tester        PASS      87.37 seconds
TestRunner_rfcomm-tester      PASS      4.41 seconds
TestRunner_sco-tester         PASS      5.54 seconds
TestRunner_ioctl-tester       PASS      4.61 seconds
TestRunner_mesh-tester        PASS      5.46 seconds
TestRunner_smp-tester         PASS      4.30 seconds
TestRunner_userchan-tester    PASS      3.16 seconds
TestRunner_6lowpan-tester     PASS      10.85 seconds
IncrementalBuild              PASS      27.78 seconds



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

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: hci_sync: Use the advertising set handle, not the instance

[Weihong Guan]

Hi Luiz,

Gentle ping on this one. It still applies cleanly to bluetooth-next
(hunks offset by 10 lines), and both commands still send the instance
number as the advertising handle there, so a controller with a single
advertising set still can't start an instance that uses a random address,
or remove instance 1.

Happy to rework it if you'd rather handle the ownership of handle 0x00
differently, as noted below the cut in the patch.

Thanks,
Weihong

Re: [PATCH] Bluetooth: hci_sync: Use the advertising set handle, not the instance

[Luiz Augusto von Dentz]

Hi,

On Tue, Nov 10, 2026 at 10:18 AM Weihong Guan <weihong.guan@gmail.com> wrote:
>
> Hi Luiz,
>
> Gentle ping on this one. It still applies cleanly to bluetooth-next
> (hunks offset by 10 lines), and both commands still send the instance
> number as the advertising handle there, so a controller with a single
> advertising set still can't start an instance that uses a random address,
> or remove instance 1.
>
> Happy to rework it if you'd rather handle the ownership of handle 0x00
> differently, as noted below the cut in the patch.

Looks like the following comments haven't been addressed:
https://sashiko.dev/#/patchset/20261023132421.1889022-1-weihong.guan%40gmail.com

> Thanks,
> Weihong



-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: hci_sync: Use the advertising set handle, not the instance

[Weihong Guan]

Hi Luiz,

On Tue, Nov 10, 2026 at 4:02 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Looks like the following comments haven't been addressed:
> https://sashiko.dev/#/patchset/20261023132421.1889022-1-weihong.guan%40gmail.com

Sorry, I hadn't seen that review. All four points held up, and v2
addresses them, with a third patch for the Advertising Set Terminated
event, where the responder address comes from:

https://lore.kernel.org/linux-bluetooth/20261111010940.728149-1-weihong.guan@gmail.com/

Thanks,
Weihong