* Re: [PATCH v2] Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING
From: Jiajia Liu @ 2026-06-03 2:45 UTC (permalink / raw)
To: Paul Menzel
Cc: Luiz Augusto von Dentz, Marcel Holtmann, linux-bluetooth,
linux-kernel, Jiajia Liu
In-Reply-To: <95453e74-636d-4a9f-91c0-189366423180@molgen.mpg.de>
On Tue, Jun 02, 2026 at 11:53:29PM +0200, Paul Menzel wrote:
> [Cc: -brian.gix@intel.com (bouncing)]
>
> Dear Luiz,
>
>
> Am 02.06.26 um 18:43 schrieb Luiz Augusto von Dentz:
>
> > On Tue, Jun 2, 2026 at 10:41 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> > > Am 02.06.26 um 09:00 schrieb Jiajia Liu:
> > > > When hci_inquiry_complete_evt is called between le_scan_disable and
> > > > le_set_scan_enable_complete and no remote name needs to be resolved,
> > > > the interleaved discovery with SIMULTANEOUS quirk gets stuck in
> > > > DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry
> > > > state. No one sets DISCOVERY_STOPPED in this process.
> > > >
> > > > Add state check in le_set_scan_enable_complete and change state if
> > > > the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell
> > >
> > > … change state to DISCOVERY_STOPPED …
> > >
> > > I’d add a new paragraph for the Tested part.
> > >
> > > > Vostro 13. Discovering disabled MGMT Event below is reported when
> > > > running into the above condition.
> > >
> > > Thank you for sharing the test device. Could you please document how to
> > > get into this state exactly? Some Xiaomi device?
> >
> > What are you talking about here by saying Xiaomi device? He literally
> > said Dell Vostro 13, a laptop, and this is a local only procedure,
> > there is no remote device involved here.
>
> In the trace below a Xiaomi device shows up, if I am not mistaken.
There should be no requirements for Bluetooth devices. To keep the serial
number of packet continuous, I didn't remove the Device Found MGMT Event.
It looks like someone's TV device.
The producer is Open the bluetooth panel of gnome-control-center and wait.
If the device list on the pannel is not flushed again and becomes empty,
it probably gets into this state. btmon or dynamic debug of
hci_discovery_set_state can confirm the state.
It think it depends on the timing of Inquiry Complete Event. There is a
very small time slot between disabling LE scan and disabling completion.
If Inquiry Complete Event arrives in the slot, there is a chance to hit
the state.
>
> > > > @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > ...
> > > > < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438
> > > > Extended scan: Enabled (0x01)
> > > > Filter duplicates: Enabled (0x01)
> > > > Duration: 0 msec (0x0000)
> > > > Period: 0.00 sec (0x0000)
> > > > > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295
> > > > LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
> > > > Status: Success (0x00)
> > > > @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > Discovery: Enabled (0x01)
> > > > < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528
> > > > Access code: 0x9e8b33 (General Inquiry)
> > > > Length: 10.24s (0x08)
> > > > Num responses: 0
> > > > > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333
> > > > Inquiry (0x01|0x0001) ncmd 2
> > > > Status: Success (0x00)
> > > > ...
> > > > < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802
> > > > Extended scan: Disabled (0x00)
> > > > Filter duplicates: Disabled (0x00)
> > > > Duration: 0 msec (0x0000)
> > > > Period: 0.00 sec (0x0000)
> > > > > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419
> > > > Status: Success (0x00)
> > > > > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378
> > > > LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
> > > > Status: Success (0x00)
> > > > @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497
> > > > LE Address: 88:12:AC:92:43:69
> > > > RSSI: -101 dBm (0x9b)
> > > > Flags: 0x00000004
> > > > Not Connectable
> > > > Data length: 8
> > > > Company: Xiaomi Inc. (911)
> > > > Data[0]:
> > > > 16-bit Service UUIDs (complete): 1 entry
> > > > Xiaomi Inc. (0xfdaa)
> > > > @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > Discovery: Disabled (0x00)
> > > >
> > > > Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync")
> > > > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - move the handler to hci_event.c
> > > > - remove unnecessary bt_dev_dbg
> > > > - update commit message
> > > >
> > > > ---
> > > > net/bluetooth/hci_event.c | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > > > index eea2f810aafa..1cd5f97daafe 100644
> > > > --- a/net/bluetooth/hci_event.c
> > > > +++ b/net/bluetooth/hci_event.c
> > > > @@ -1769,6 +1769,13 @@ static void le_set_scan_enable_complete(struct hci_dev *hdev, u8 enable)
> > > >
> > > > hci_dev_clear_flag(hdev, HCI_LE_SCAN);
> > > >
> > > > + if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
> > > > + hci_test_quirk(hdev, HCI_QUIRK_SIMULTANEOUS_DISCOVERY) &&
> > > > + !test_bit(HCI_INQUIRY, &hdev->flags) &&
> > > > + hdev->discovery.state == DISCOVERY_FINDING) {
> > > > + hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> > > > + }
> > > > +
> > > > /* The HCI_LE_SCAN_INTERRUPTED flag indicates that we
> > > > * interrupted scanning due to a connect request. Mark
> > > > * therefore discovery as stopped.
>
>
> Kind regards,
>
> Paul
^ permalink raw reply
* RE: Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: bluez.test.bot @ 2026-06-03 2:40 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <20260602233414.209730-1-jaggyaur@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3383 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/project/bluetooth/list/?series=1104912
---Test result---
Test Summary:
CheckPatch FAIL 0.73 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.42 seconds
CheckAllWarning PASS 27.84 seconds
CheckSparse PASS 27.29 seconds
BuildKernel32 PASS 25.11 seconds
TestRunnerSetup PASS 528.65 seconds
TestRunner_l2cap-tester PASS 61.14 seconds
TestRunner_iso-tester PASS 81.68 seconds
TestRunner_bnep-tester PASS 19.35 seconds
TestRunner_mgmt-tester FAIL 212.14 seconds
TestRunner_rfcomm-tester PASS 25.82 seconds
TestRunner_sco-tester PASS 32.74 seconds
TestRunner_ioctl-tester PASS 26.06 seconds
TestRunner_mesh-tester FAIL 26.17 seconds
TestRunner_smp-tester PASS 23.85 seconds
TestRunner_userchan-tester PASS 20.29 seconds
TestRunner_6lowpan-tester PASS 22.90 seconds
IncrementalBuild PASS 25.01 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: Fix Use-After-Free in hci_unregister_dev
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#94:
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
WARNING: From:/Signed-off-by: email address mismatch: 'From: Jordan Walters <jaggyaur@gmail.com>' != 'Signed-off-by: Jordan Walters <gloambit@gloam.sh>'
total: 0 errors, 2 warnings, 0 checks, 8 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.
/github/workspace/src/patch/14608047.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: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: Fix Use-After-Free in hci_unregister_dev
8: B1 Line exceeds max length (81>80): "This patch adds the necessary disable_delayed_work_sync() calls to securely flush"
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.239 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.518 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
https://github.com/bluez/bluetooth-next/pull/278
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-02 23:34 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
before freeing the hci_dev structure. If an asynchronous event or timeout occurs
during device teardown, the timer callbacks may execute after the device has
been freed, leading to a KASAN slab-use-after-free panic.
This patch adds the necessary disable_delayed_work_sync() calls to securely flush
the timers before the teardown sequence proceeds.
Signed-off-by: Jordan Walters <gloambit@gloam.sh>
---
net/bluetooth/hci_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28d7929dc59..1cbc666527c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2671,6 +2671,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
disable_work_sync(&hdev->tx_work);
disable_work_sync(&hdev->power_on);
disable_work_sync(&hdev->error_reset);
+ disable_delayed_work_sync(&hdev->cmd_timer);
+ disable_delayed_work_sync(&hdev->ncmd_timer);
hci_cmd_sync_clear(hdev);
^ permalink raw reply related
* RE: [BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active
From: bluez.test.bot @ 2026-06-02 22:27 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602210022.213562-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1287 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/project/bluetooth/list/?series=1104856
---Test result---
Test Summary:
CheckPatch PASS 1.75 seconds
GitLint FAIL 1.01 seconds
BuildEll PASS 20.78 seconds
BluezMake PASS 686.70 seconds
MakeCheck PASS 18.37 seconds
MakeDistcheck PASS 252.36 seconds
CheckValgrind PASS 298.96 seconds
CheckSmatch PASS 352.74 seconds
bluezmakeextell PASS 185.30 seconds
IncrementalBuild PASS 687.41 seconds
ScanBuild PASS 1066.94 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active
1: T1 Title exceeds max length (83>80): "[BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active"
https://github.com/bluez/bluez/pull/2168
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v1] advertising: Fix sending extra bytes with MGMT_OP_ADD_EXT_ADV_DATA
From: bluez.test.bot @ 2026-06-02 22:16 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602204749.210857-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1192 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/project/bluetooth/list/?series=1104846
---Test result---
Test Summary:
CheckPatch PASS 2.26 seconds
GitLint PASS 0.37 seconds
BuildEll PASS 20.58 seconds
BluezMake PASS 696.31 seconds
CheckSmatch WARNING 355.44 seconds
bluezmakeextell PASS 182.82 seconds
IncrementalBuild PASS 668.57 seconds
ScanBuild PASS 1026.46 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capabilitysrc/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capability
https://github.com/bluez/bluez/pull/2167
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v1] Bluetooth: MGMT: Fix backward compatibility with userspace
From: bluez.test.bot @ 2026-06-02 22:09 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602205659.212834-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1718 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/project/bluetooth/list/?series=1104852
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 27.61 seconds
CheckAllWarning PASS 29.95 seconds
CheckSparse PASS 28.55 seconds
BuildKernel32 PASS 26.59 seconds
TestRunnerSetup PASS 590.34 seconds
TestRunner_mgmt-tester FAIL 223.41 seconds
TestRunner_mesh-tester FAIL 27.00 seconds
IncrementalBuild PASS 26.37 seconds
Details
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.253 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.645 seconds
Mesh - Send cancel - 2 Timed out 1.988 seconds
https://github.com/bluez/bluetooth-next/pull/277
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: bluez.test.bot @ 2026-06-02 22:04 UTC (permalink / raw)
To: linux-bluetooth, i
In-Reply-To: <20260603-btmtk-remote-wakeup-v1-1-5c1006442f36@rong.moe>
[-- Attachment #1: Type: text/plain, Size: 2165 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/project/bluetooth/list/?series=1104801
---Test result---
Test Summary:
CheckPatch PASS 0.73 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.53 seconds
CheckAllWarning PASS 28.28 seconds
CheckSparse PASS 26.92 seconds
BuildKernel32 PASS 26.17 seconds
TestRunnerSetup PASS 531.27 seconds
IncrementalBuild PASS 24.77 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
27: B1 Line exceeds max length (86>80): " [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
28: B1 Line exceeds max length (86>80): " [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
31: B1 Line exceeds max length (86>80): " [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
32: B1 Line exceeds max length (86>80): " [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
52: B1 Line exceeds max length (86>80): " [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
53: B1 Line exceeds max length (86>80): " [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
56: B1 Line exceeds max length (86>80): " [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
57: B1 Line exceeds max length (86>80): " [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
https://github.com/bluez/bluetooth-next/pull/276
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Add support for TP-Link TL-UB250
From: Paul Menzel @ 2026-06-02 22:03 UTC (permalink / raw)
To: Cris; +Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260602135419.3092500-1-cxs1494089474@gmail.com>
Dear Cris,
Thank you for your patch.
Am 02.06.26 um 15:54 schrieb Cris:
> Add USB ID 2357:0607 for TP-Link TL-UB250.
>
> This is a Realtek RTL8761BUV based Bluetooth adapter.
>
> Without this entry the device is picked up by the generic Bluetooth USB
> class match and exposes hci0, but the Realtek setup path is not used and
> rtl8761bu firmware/config are not loaded.
>
> The controller reports Realtek Semiconductor Corporation as the
> manufacturer and LMP subversion 0x8761. With this entry added, btusb
> loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin
> successfully.
>
> Use the same flags as the existing TP-Link 2357:0604 entry.
Please add the relevant part of `/sys/kernel/debug/usb/devices` to the
commit message [1]
> Cc: stable@vger.kernel.org
> Signed-off-by: Cris <cxs1494089474@gmail.com>
If possible, a full name would be nice.
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3aef21d4c..3cbb3c22e 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -831,6 +831,8 @@ static const struct usb_device_id quirks_table[] = {
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
> BTUSB_WIDEBAND_SPEECH },
> + { USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
> + BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x2550, 0x8761), .driver_info = BTUSB_REALTEK |
With the commit message improved, please feel free to add:
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
[1]:
https://lore.kernel.org/linux-bluetooth/20260530123934.4583-1-nils.helmig@web.de/
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING
From: Paul Menzel @ 2026-06-02 21:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Jiajia Liu, Marcel Holtmann, linux-bluetooth, linux-kernel,
Jiajia Liu
In-Reply-To: <CABBYNZK1GLGu+xdKng3O4b=NrNwxB6ZAyfXSn8DE4WptXN=5CQ@mail.gmail.com>
[Cc: -brian.gix@intel.com (bouncing)]
Dear Luiz,
Am 02.06.26 um 18:43 schrieb Luiz Augusto von Dentz:
> On Tue, Jun 2, 2026 at 10:41 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>> Am 02.06.26 um 09:00 schrieb Jiajia Liu:
>>> When hci_inquiry_complete_evt is called between le_scan_disable and
>>> le_set_scan_enable_complete and no remote name needs to be resolved,
>>> the interleaved discovery with SIMULTANEOUS quirk gets stuck in
>>> DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry
>>> state. No one sets DISCOVERY_STOPPED in this process.
>>>
>>> Add state check in le_set_scan_enable_complete and change state if
>>> the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell
>>
>> … change state to DISCOVERY_STOPPED …
>>
>> I’d add a new paragraph for the Tested part.
>>
>>> Vostro 13. Discovering disabled MGMT Event below is reported when
>>> running into the above condition.
>>
>> Thank you for sharing the test device. Could you please document how to
>> get into this state exactly? Some Xiaomi device?
>
> What are you talking about here by saying Xiaomi device? He literally
> said Dell Vostro 13, a laptop, and this is a local only procedure,
> there is no remote device involved here.
In the trace below a Xiaomi device shows up, if I am not mistaken.
>>> @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873
>>> Address type: 0x07
>>> BR/EDR
>>> LE Public
>>> LE Random
>>> ...
>>> < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438
>>> Extended scan: Enabled (0x01)
>>> Filter duplicates: Enabled (0x01)
>>> Duration: 0 msec (0x0000)
>>> Period: 0.00 sec (0x0000)
>>> > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295
>>> LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
>>> Status: Success (0x00)
>>> @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414
>>> Address type: 0x07
>>> BR/EDR
>>> LE Public
>>> LE Random
>>> Discovery: Enabled (0x01)
>>> < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528
>>> Access code: 0x9e8b33 (General Inquiry)
>>> Length: 10.24s (0x08)
>>> Num responses: 0
>>> > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333
>>> Inquiry (0x01|0x0001) ncmd 2
>>> Status: Success (0x00)
>>> ...
>>> < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802
>>> Extended scan: Disabled (0x00)
>>> Filter duplicates: Disabled (0x00)
>>> Duration: 0 msec (0x0000)
>>> Period: 0.00 sec (0x0000)
>>> > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419
>>> Status: Success (0x00)
>>> > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378
>>> LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
>>> Status: Success (0x00)
>>> @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497
>>> LE Address: 88:12:AC:92:43:69
>>> RSSI: -101 dBm (0x9b)
>>> Flags: 0x00000004
>>> Not Connectable
>>> Data length: 8
>>> Company: Xiaomi Inc. (911)
>>> Data[0]:
>>> 16-bit Service UUIDs (complete): 1 entry
>>> Xiaomi Inc. (0xfdaa)
>>> @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506
>>> Address type: 0x07
>>> BR/EDR
>>> LE Public
>>> LE Random
>>> Discovery: Disabled (0x00)
>>>
>>> Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync")
>>> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
>>> ---
>>>
>>> Changes in v2:
>>> - move the handler to hci_event.c
>>> - remove unnecessary bt_dev_dbg
>>> - update commit message
>>>
>>> ---
>>> net/bluetooth/hci_event.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>>> index eea2f810aafa..1cd5f97daafe 100644
>>> --- a/net/bluetooth/hci_event.c
>>> +++ b/net/bluetooth/hci_event.c
>>> @@ -1769,6 +1769,13 @@ static void le_set_scan_enable_complete(struct hci_dev *hdev, u8 enable)
>>>
>>> hci_dev_clear_flag(hdev, HCI_LE_SCAN);
>>>
>>> + if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
>>> + hci_test_quirk(hdev, HCI_QUIRK_SIMULTANEOUS_DISCOVERY) &&
>>> + !test_bit(HCI_INQUIRY, &hdev->flags) &&
>>> + hdev->discovery.state == DISCOVERY_FINDING) {
>>> + hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
>>> + }
>>> +
>>> /* The HCI_LE_SCAN_INTERRUPTED flag indicates that we
>>> * interrupted scanning due to a connect request. Mark
>>> * therefore discovery as stopped.
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH] Bluetooth: MGMT: validate Add Extended Advertising Data length
From: Michael Bommarito @ 2026-06-02 21:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Daniel Winkler, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZKh-J9sHf3ma=HJTBz=j0QL+eEti_0hOAJU=4Okm4Lz1A@mail.gmail.com>
On Tue, Jun 2, 2026 at 4:17 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> That is probably a bug in bluetoothd but it breaks backward compatibility.
Ah, darn. Should we config gate the kernel side to make it easier for
distros to decide or make backport decisions easier? Or just hold
back on pulling the change unless / until the bluetoothd issues are
resolved?
Thanks,
Mike
^ permalink raw reply
* RE: Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: bluez.test.bot @ 2026-06-02 21:39 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <CACXZaU47FFpcucqfAsVz3nWQL8m6shuEav=bz4-8FL315fZDpA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: net/bluetooth/hci_core.c:2671
error: net/bluetooth/hci_core.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 68ea8a: profiles/audio/bass: Use BASS_Modify_Source when a...
From: Luiz Augusto von Dentz @ 2026-06-02 21:26 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1104856
Home: https://github.com/bluez/bluez
Commit: 68ea8abc431536ceb035c81f58a9380350765616
https://github.com/bluez/bluez/commit/68ea8abc431536ceb035c81f58a9380350765616
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-06-02 (Tue, 02 Jun 2026)
Changed paths:
M profiles/audio/bass.c
Log Message:
-----------
profiles/audio/bass: Use BASS_Modify_Source when assistant is active
When a MediaAssistant is already active (streaming), a subsequent Push
should send Modify Source with PA_SYNC_NO_SYNC and bis_sync=0 to
remove the broadcast source, rather than adding a duplicate source.
Split push() into push_add_src() and push_mod_src() helpers. The push
dispatcher checks the assistant state: ACTIVE non-local assistants and
LOCAL assistants with a tracked source entry both route to
push_mod_src, while all others proceed with push_add_src.
Add per-device source tracking for LOCAL assistants via a bass_src
struct (keyed by bt_bass pointer) stored in a per-assistant srcs
queue. This is needed because LOCAL assistants never change state, so
we cannot rely on the state machine alone to detect active sources.
Also fix the bass_src_changed BID filter: the previous check rejected
non-local assistants when BID was zero, but this incorrectly excluded
LOCAL assistants in REQUESTING state whose BID happens to be non-zero.
Change to reject assistants whose own BID is non-zero when the
notification BID is zero, which correctly matches local streams.
Commit: 916f13168fadded01ecf4b5ff38d6778e7f43607
https://github.com/bluez/bluez/commit/916f13168fadded01ecf4b5ff38d6778e7f43607
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-06-02 (Tue, 02 Jun 2026)
Changed paths:
M profiles/audio/bass.c
M src/shared/bass.c
Log Message:
-----------
profiles/audio/bass: Handle PA_SYNC_NO_SYNC in handle_mod_src_req
When the delegator receives a Modify Source operation with pa_sync set
to PA_SYNC_NO_SYNC while already synchronized to PA, release all
setups instead of updating BIS sync which would not apply the
requested termination.
Also reset the encryption state to no encryption when the last BIS
index is cleared from a subgroup, so subsequent source additions
start with a clean encryption state.
Commit: 6086c0bddadba995f868ede7a730a6ff33c6b7da
https://github.com/bluez/bluez/commit/6086c0bddadba995f868ede7a730a6ff33c6b7da
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-06-02 (Tue, 02 Jun 2026)
Changed paths:
M profiles/audio/bass.c
Log Message:
-----------
profiles/audio/bass: Fix delegator reprobing after disconnect
delegator_disconnect left the old delegator in the delegators queue
after calling device_remove_profile. When a new delegator was created
for the same device (e.g. on a subsequent Add Source after Modify
Source removal), delegator_attach would find the stale entry and
return early, leaving the new delegator without a service. This
caused the "Unable to probe service" error and prevented the BASS
bcode exchange from working on reconnection.
Fix by removing the delegator from the queue, clearing service user
data, and calling delegator_free before disconnecting the service
and removing the profile. This also fixes a potential use-after-free
where delegator_disconnect accessed dg fields after device_remove_profile
could trigger delegator_detach -> delegator_free through the
bap_detached callback chain.
Also add validation in bass_req_bcode to detect and discard invalid
(all-zeros) broadcast codes that may have been stored from a previous
connection.
Commit: 269d2a4f137316ab45db0cc767f2995bfd4c6bf9
https://github.com/bluez/bluez/commit/269d2a4f137316ab45db0cc767f2995bfd4c6bf9
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-06-02 (Tue, 02 Jun 2026)
Changed paths:
M doc/org.bluez.MediaAssistant.rst
Log Message:
-----------
doc: Document Push behavior when MediaAssistant is active
Document that calling Push on an assistant already in active state uses
BASS_Modify_Source to update the existing source rather than adding a
new one.
Compare: https://github.com/bluez/bluez/compare/68ea8abc4315%5E...269d2a4f1373
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] c3ed9c: advertising: Fix sending extra bytes with MGMT_OP_...
From: Luiz Augusto von Dentz @ 2026-06-02 21:26 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1104846
Home: https://github.com/bluez/bluez
Commit: c3ed9c6105d29ee0bd563f2d33a181d218cf1b4a
https://github.com/bluez/bluez/commit/c3ed9c6105d29ee0bd563f2d33a181d218cf1b4a
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-06-02 (Tue, 02 Jun 2026)
Changed paths:
M src/advertising.c
Log Message:
-----------
advertising: Fix sending extra bytes with MGMT_OP_ADD_EXT_ADV_DATA
MGMT_OP_ADD_EXT_ADV_DATA expects the command to be of size of
struct mgmt_cp_add_ext_adv_data not mgmt_cp_add_advertising.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-02 21:10 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
before freeing the hci_dev structure. If an asynchronous event or timeout occurs
during device teardown, the timer callbacks may execute after the device has
been freed, leading to a KASAN slab-use-after-free panic.
This patch adds the necessary disable_delayed_work_sync() calls to
securely flush
the timers before the teardown sequence proceeds.
Signed-off-by: Jordan Walters <gloambit@gloam.sh>
---
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a1b2c3d4e..f5g6h7i8j 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2671,6 +2671,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
hci_dev_do_close(hdev);
hci_cancel_cmd_sync(hdev, -ENODEV);
+ disable_delayed_work_sync(&hdev->cmd_timer);
+ disable_delayed_work_sync(&hdev->ncmd_timer);
/* Sync with hci_rx_work */
cancel_work_sync(&hdev->rx_work);
^ permalink raw reply
* [PATCH] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-02 21:05 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel; +Cc: Luiz Augusto von Dentz, marcel@holtmann.org
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
before freeing the hci_dev structure. If an asynchronous event or timeout occurs
during device teardown, the timer callbacks may execute after the device has
been freed, leading to a KASAN slab-use-after-free panic.
This patch adds the necessary disable_delayed_work_sync() calls to
securely flush
the timers before the teardown sequence proceeds.
Signed-off-by: Jordan Walters <gloambit@gloam.sh>
---
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a1b2c3d4e..f5g6h7i8j 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2671,6 +2671,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
hci_dev_do_close(hdev);
hci_cancel_cmd_sync(hdev, -ENODEV);
+ disable_delayed_work_sync(&hdev->cmd_timer);
+ disable_delayed_work_sync(&hdev->ncmd_timer);
/* Sync with hci_rx_work */
cancel_work_sync(&hdev->rx_work);
^ permalink raw reply
* [PATCH BlueZ v1 4/4] doc: Document Push behavior when MediaAssistant is active
From: Luiz Augusto von Dentz @ 2026-06-02 21:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260602210022.213562-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Document that calling Push on an assistant already in active state uses
BASS_Modify_Source to update the existing source rather than adding a
new one.
---
doc/org.bluez.MediaAssistant.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/org.bluez.MediaAssistant.rst b/doc/org.bluez.MediaAssistant.rst
index 45143cee8dbf..2f29a7b5c253 100644
--- a/doc/org.bluez.MediaAssistant.rst
+++ b/doc/org.bluez.MediaAssistant.rst
@@ -27,6 +27,10 @@ void Push(dict properties)
Send stream information to the remote device.
+If the assistant is in the "active" state, this method uses
+BASS_Modify_Source to update the existing source on the remote device
+instead of adding a new one with BASS_Add_Source.
+
:dict properties:
Indicate stream properties that will be sent to the peer.
--
2.54.0
^ permalink raw reply related
* [PATCH BlueZ v1 3/4] profiles/audio/bass: Fix delegator reprobing after disconnect
From: Luiz Augusto von Dentz @ 2026-06-02 21:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260602210022.213562-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
delegator_disconnect left the old delegator in the delegators queue
after calling device_remove_profile. When a new delegator was created
for the same device (e.g. on a subsequent Add Source after Modify
Source removal), delegator_attach would find the stale entry and
return early, leaving the new delegator without a service. This
caused the "Unable to probe service" error and prevented the BASS
bcode exchange from working on reconnection.
Fix by removing the delegator from the queue, clearing service user
data, and calling delegator_free before disconnecting the service
and removing the profile. This also fixes a potential use-after-free
where delegator_disconnect accessed dg fields after device_remove_profile
could trigger delegator_detach -> delegator_free through the
bap_detached callback chain.
Also add validation in bass_req_bcode to detect and discard invalid
(all-zeros) broadcast codes that may have been stored from a previous
connection.
---
profiles/audio/bass.c | 35 ++++++++++++++++++++++++++++++-----
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/profiles/audio/bass.c b/profiles/audio/bass.c
index 5eb7bff076bb..a5ef80fbc835 100644
--- a/profiles/audio/bass.c
+++ b/profiles/audio/bass.c
@@ -257,9 +257,17 @@ static void bass_req_bcode(struct bt_bap_stream *stream,
}
if (dg->bcode) {
- /* Broadcast Code has already been received before. */
- setup_set_bcode(dg->bcode, setup, reply, reply_data);
- return;
+ uint8_t empty_bcode[BT_BASS_BCAST_CODE_SIZE] = {0};
+
+ if (memcmp(dg->bcode, empty_bcode, BT_BASS_BCAST_CODE_SIZE)) {
+ /* Broadcast Code has already been received before. */
+ setup_set_bcode(dg->bcode, setup, reply, reply_data);
+ return;
+ }
+
+ error("dg %p has invalid bcode", dg);
+ free(dg->bcode);
+ dg->bcode = NULL;
}
/* Create a request for the Broadcast Code. The request
@@ -376,20 +384,37 @@ static void setup_free(void *data)
free(setup);
}
+static void delegator_free(struct bass_delegator *dg);
+
static void delegator_disconnect(struct bass_delegator *dg)
{
struct btd_device *device = dg->device;
struct btd_service *service = dg->service;
+ struct btd_profile *profile = btd_service_get_profile(service);
DBG("%p", dg);
+ /* Remove delegator from the queue and free it before removing the
+ * service profile. This prevents delegator_attach from finding a
+ * stale entry when a new delegator is created for the same device,
+ * and also avoids use-after-free since device_remove_profile may
+ * trigger bap_detached -> delegator_detach which would otherwise
+ * try to free the delegator again.
+ */
+ queue_remove(delegators, dg);
+ btd_service_set_user_data(service, NULL);
+ delegator_free(dg);
+
/* Disconnect service so BAP driver is cleanup properly and bt_bap is
* detached from the device.
*/
btd_service_disconnect(service);
- /* Remove service since delegator shold have been freed at this point */
- device_remove_profile(device, btd_service_get_profile(service));
+ /* Remove service since delegator has been freed at this point.
+ * delegator_detach (triggered by bap_detached) will be a no-op
+ * since the delegator has already been removed from the queue.
+ */
+ device_remove_profile(device, profile);
/* If the device is no longer consider connected it means no other
* service was connected so it has no longer any use and can be safely
--
2.54.0
^ permalink raw reply related
* [PATCH BlueZ v1 2/4] profiles/audio/bass: Handle PA_SYNC_NO_SYNC in handle_mod_src_req
From: Luiz Augusto von Dentz @ 2026-06-02 21:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260602210022.213562-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When the delegator receives a Modify Source operation with pa_sync set
to PA_SYNC_NO_SYNC while already synchronized to PA, release all
setups instead of updating BIS sync which would not apply the
requested termination.
Also reset the encryption state to no encryption when the last BIS
index is cleared from a subgroup, so subsequent source additions
start with a clean encryption state.
---
profiles/audio/bass.c | 72 ++++++++++++++++++++++++++++++++++++++++---
src/shared/bass.c | 6 ++++
2 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/profiles/audio/bass.c b/profiles/audio/bass.c
index f018f8b3ad7f..5eb7bff076bb 100644
--- a/profiles/audio/bass.c
+++ b/profiles/audio/bass.c
@@ -420,7 +420,13 @@ static void setup_clear(struct bass_setup *setup, int bis)
bt_bass_clear_bis_sync(dg->src, bis);
setup->stream = NULL;
- queue_remove(setup->dg->setups, setup);
+
+ if (!queue_remove(setup->dg->setups, setup))
+ /* Setup has already been removed from the queue (e.g. during
+ * handle_mod_src_req PA_SYNC_NO_SYNC processing). Skip
+ * disconnect check and free since the caller handles cleanup.
+ */
+ return;
/* Remove any pending bcode request associated with setup */
req = queue_remove_if(dg->bcode_reqs, match_bcode_setup, setup);
@@ -596,6 +602,8 @@ static void bass_remove_bis(struct bass_setup *setup)
{
struct queue *links = bt_bap_stream_io_get_links(setup->stream);
+ DBG("%p", setup);
+
queue_foreach(links, stream_unlink, setup->stream);
bt_bap_stream_release(setup->stream, NULL, NULL);
}
@@ -618,6 +626,8 @@ static void setup_disable_streaming(void *data, void *user_data)
static void bass_add_bis(struct bass_setup *setup)
{
+ DBG("%p", setup);
+
queue_foreach(setup->dg->setups, setup_disable_streaming, NULL);
setup_configure_stream(setup);
}
@@ -1941,8 +1951,40 @@ static int handle_set_bcode_req(struct bt_bcast_src *bcast_src,
return 0;
}
+static bool check_bis_sync(struct bt_bass_mod_src_params *params, uint8_t bis)
+{
+ uint32_t bitmask = 1 << (bis - 1);
+ struct iovec iov = {
+ .iov_base = params->subgroup_data,
+ .iov_len = 0,
+ };
+
+ /* Calculate subgroup data length based on each subgroup's
+ * bis_sync (4 bytes) + meta_len (1 byte) + meta fields.
+ */
+ for (uint8_t i = 0; i < params->num_subgroups; i++) {
+ uint32_t bis_sync;
+ uint8_t meta_len;
+
+ iov.iov_len += sizeof(bis_sync) + sizeof(meta_len);
+
+ memcpy(&bis_sync, params->subgroup_data + iov.iov_len -
+ sizeof(bis_sync) - sizeof(meta_len),
+ sizeof(bis_sync));
+ memcpy(&meta_len, params->subgroup_data + iov.iov_len -
+ sizeof(meta_len), sizeof(meta_len));
+
+ if (le32_to_cpu(bis_sync) & bitmask)
+ return true;
+
+ iov.iov_len += meta_len;
+ }
+
+ return false;
+}
+
static void bass_update_bis_sync(struct bass_delegator *dg,
- struct bt_bcast_src *bcast_src)
+ struct bt_bass_mod_src_params *params)
{
const struct queue_entry *entry;
@@ -1954,11 +1996,14 @@ static void bass_update_bis_sync(struct bass_delegator *dg,
state = bt_bap_stream_get_state(setup->stream);
- if (!setup->stream && bt_bass_check_bis(bcast_src, setup->bis))
+ DBG("stream %p: BIS %d state %s(%u)", setup->stream, setup->bis,
+ bt_bap_stream_statestr(state), state);
+
+ if (!setup->stream && check_bis_sync(params, setup->bis))
bass_add_bis(setup);
else if (setup->stream &&
state == BT_BAP_STREAM_STATE_STREAMING &&
- !bt_bass_check_bis(bcast_src, setup->bis))
+ !check_bis_sync(params, setup->bis))
bass_remove_bis(setup);
}
}
@@ -1981,9 +2026,26 @@ static int handle_mod_src_req(struct bt_bcast_src *bcast_src,
if (err)
return err;
+ DBG("PA sync state %d", sync_state);
+
switch (sync_state) {
case BT_BASS_SYNCHRONIZED_TO_PA:
- bass_update_bis_sync(dg, bcast_src);
+ if (params->pa_sync == PA_SYNC_NO_SYNC) {
+ /* Release all setups. Note: bass_remove_bis may
+ * trigger synchronous state transitions that call
+ * setup_clear which will return early since the
+ * setup has already been removed from the queue.
+ */
+ struct bass_setup *setup;
+
+ while ((setup = queue_pop_head(dg->setups))) {
+ bass_remove_bis(setup);
+ setup_free(setup);
+ }
+
+ delegator_disconnect(dg);
+ } else
+ bass_update_bis_sync(dg, params);
break;
case BT_BASS_NOT_SYNCHRONIZED_TO_PA:
if (params->pa_sync == PA_SYNC_NO_PAST) {
diff --git a/src/shared/bass.c b/src/shared/bass.c
index 19cc9531d617..65ee4a8cbb18 100644
--- a/src/shared/bass.c
+++ b/src/shared/bass.c
@@ -1930,6 +1930,12 @@ int bt_bass_clear_bis_sync(struct bt_bcast_src *bcast_src, uint8_t bis)
if (sgrp->bis_sync & bitmask) {
sgrp->bis_sync &= ~bitmask;
+ /* If there are no BIS index left then reset encryption
+ * state to no encryption.
+ */
+ if (!sgrp->bis_sync)
+ bcast_src->enc = BT_BASS_BIG_ENC_STATE_NO_ENC;
+
iov = bass_parse_bcast_src(bcast_src);
if (!iov)
return -ENOMEM;
--
2.54.0
^ permalink raw reply related
* [PATCH BlueZ v1 1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active
From: Luiz Augusto von Dentz @ 2026-06-02 21:00 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When a MediaAssistant is already active (streaming), a subsequent Push
should send Modify Source with PA_SYNC_NO_SYNC and bis_sync=0 to
remove the broadcast source, rather than adding a duplicate source.
Split push() into push_add_src() and push_mod_src() helpers. The push
dispatcher checks the assistant state: ACTIVE non-local assistants and
LOCAL assistants with a tracked source entry both route to
push_mod_src, while all others proceed with push_add_src.
Add per-device source tracking for LOCAL assistants via a bass_src
struct (keyed by bt_bass pointer) stored in a per-assistant srcs
queue. This is needed because LOCAL assistants never change state, so
we cannot rely on the state machine alone to detect active sources.
Also fix the bass_src_changed BID filter: the previous check rejected
non-local assistants when BID was zero, but this incorrectly excluded
LOCAL assistants in REQUESTING state whose BID happens to be non-zero.
Change to reject assistants whose own BID is non-zero when the
notification BID is zero, which correctly matches local streams.
---
profiles/audio/bass.c | 176 +++++++++++++++++++++++++++++++++++-------
1 file changed, 150 insertions(+), 26 deletions(-)
diff --git a/profiles/audio/bass.c b/profiles/audio/bass.c
index 1fd7704a77a2..f018f8b3ad7f 100644
--- a/profiles/audio/bass.c
+++ b/profiles/audio/bass.c
@@ -108,9 +108,16 @@ struct bass_assistant {
struct iovec *meta;
struct iovec *caps;
enum assistant_state state;
+ uint8_t src_id;
+ struct queue *srcs; /* Per-device source tracking */
char *path;
};
+struct bass_src {
+ struct bt_bass *bass;
+ uint8_t src_id;
+};
+
struct bass_delegator {
struct btd_device *device; /* Broadcast source device */
struct btd_service *service;
@@ -158,6 +165,17 @@ static void bass_data_remove(struct bass_data *data);
static void bis_probe(uint8_t sid, uint8_t bis, uint8_t sgrp,
struct iovec *caps, struct iovec *meta,
struct bt_bap_qos *qos, void *user_data);
+
+static bool match_src_data(const void *data, const void *match_data)
+{
+ const struct bass_src *src = data;
+ const struct bt_bass *bass = match_data;
+
+ return src->bass == bass;
+}
+
+static struct bass_src *assistant_add_src(struct bass_assistant *assistant,
+ struct bt_bass *bass, uint8_t id);
static void bis_remove(struct bt_bap *bap, void *user_data);
@@ -1010,35 +1028,62 @@ static void assistant_past(struct bass_assistant *assistant)
free(addr);
}
-static DBusMessage *push(DBusConnection *conn, DBusMessage *msg,
- void *user_data)
+static DBusMessage *push_mod_src(struct bass_assistant *assistant,
+ DBusMessage *msg)
+{
+ struct bt_bass_bcast_audio_scan_cp_hdr hdr;
+ struct bt_bass_mod_src_params params = {0};
+ struct iovec iov = {0};
+ uint32_t bis_sync = 0;
+ uint8_t meta_len = 0;
+ int err;
+
+ hdr.op = BT_BASS_MOD_SRC;
+
+ params.id = assistant->src_id;
+ params.pa_sync = PA_SYNC_NO_SYNC;
+ params.pa_interval = PA_INTERVAL_UNKNOWN;
+ params.num_subgroups = assistant->sgrp + 1;
+
+ util_iov_append(&iov, ¶ms, sizeof(params));
+
+ for (uint8_t sgrp = 0; sgrp < params.num_subgroups; sgrp++) {
+ util_iov_append(&iov, &bis_sync, sizeof(bis_sync));
+ util_iov_append(&iov, &meta_len, sizeof(meta_len));
+ }
+
+ err = bt_bass_send(assistant->data->bass, &hdr, &iov);
+ if (err) {
+ DBG("Unable to send BASS Write Command");
+ return btd_error_failed(msg, strerror(-err));
+ }
+
+ free(iov.iov_base);
+
+ if (assistant->device) {
+ assistant_set_state(assistant, ASSISTANT_STATE_IDLE);
+ } else {
+ struct bass_src *src;
+
+ src = queue_remove_if(assistant->srcs, match_src_data,
+ assistant->data->bass);
+ free(src);
+ }
+
+ return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
+}
+
+static DBusMessage *push_add_src(struct bass_assistant *assistant,
+ DBusMessage *msg)
{
- struct bass_assistant *assistant = user_data;
struct bt_bass_bcast_audio_scan_cp_hdr hdr;
struct bt_bass_add_src_params params = {0};
struct iovec iov = {0};
uint32_t bis_sync = 0;
uint8_t meta_len = 0;
int err;
- DBusMessageIter props, dict;
struct io *io;
- DBG("");
-
- dbus_message_iter_init(msg, &props);
-
- if (dbus_message_iter_get_arg_type(&props) != DBUS_TYPE_ARRAY) {
- DBG("Unable to parse properties");
- return btd_error_invalid_args(msg);
- }
-
- dbus_message_iter_recurse(&props, &dict);
-
- if (assistant_parse_props(assistant, &dict)) {
- DBG("Unable to parse properties");
- return btd_error_invalid_args(msg);
- }
-
hdr.op = BT_BASS_ADD_SRC;
if (assistant->device) {
@@ -1130,11 +1175,52 @@ static DBusMessage *push(DBusConnection *conn, DBusMessage *msg,
free(iov.iov_base);
- assistant_set_state(assistant, ASSISTANT_STATE_PENDING);
+ if (assistant->state == ASSISTANT_STATE_LOCAL)
+ assistant_add_src(assistant, assistant->data->bass, 0);
+ else
+ assistant_set_state(assistant, ASSISTANT_STATE_PENDING);
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
+static DBusMessage *push(DBusConnection *conn, DBusMessage *msg,
+ void *user_data)
+{
+ struct bass_assistant *assistant = user_data;
+ DBusMessageIter props, dict;
+
+ DBG("");
+
+ dbus_message_iter_init(msg, &props);
+
+ if (dbus_message_iter_get_arg_type(&props) != DBUS_TYPE_ARRAY) {
+ DBG("Unable to parse properties");
+ return btd_error_invalid_args(msg);
+ }
+
+ dbus_message_iter_recurse(&props, &dict);
+
+ if (assistant_parse_props(assistant, &dict)) {
+ DBG("Unable to parse properties");
+ return btd_error_invalid_args(msg);
+ }
+
+ if (assistant->state == ASSISTANT_STATE_ACTIVE) {
+ return push_mod_src(assistant, msg);
+ } else if (assistant->state == ASSISTANT_STATE_LOCAL) {
+ struct bass_src *src;
+
+ src = queue_find(assistant->srcs, match_src_data,
+ assistant->data->bass);
+ if (src) {
+ assistant->src_id = src->src_id;
+ return push_mod_src(assistant, msg);
+ }
+ }
+
+ return push_add_src(assistant, msg);
+}
+
static const GDBusMethodTable assistant_methods[] = {
{GDBUS_EXPERIMENTAL_ASYNC_METHOD("Push",
GDBUS_ARGS({ "Props", "a{sv}" }),
@@ -1235,6 +1321,7 @@ static void assistant_free(void *data)
g_free(assistant->path);
util_iov_free(assistant->meta, 1);
util_iov_free(assistant->caps, 1);
+ queue_destroy(assistant->srcs, free);
free(assistant);
}
@@ -2015,9 +2102,33 @@ static void bass_handle_bcode_req(struct bass_assistant *assistant, int id)
free(iov.iov_base);
}
+static struct bass_src *assistant_add_src(struct bass_assistant *assistant,
+ struct bt_bass *bass, uint8_t id)
+{
+ struct bass_src *src;
+
+ if (!assistant->srcs)
+ assistant->srcs = queue_new();
+
+ src = queue_find(assistant->srcs, match_src_data, bass);
+ if (src) {
+ src->src_id = id;
+ return src;
+ }
+
+ src = new0(struct bass_src, 1);
+ src->bass = bass;
+ src->src_id = id;
+
+ queue_push_tail(assistant->srcs, src);
+
+ return src;
+}
+
static void bass_src_changed(uint8_t id, uint32_t bid, uint8_t state,
uint8_t enc, uint32_t bis_sync, void *user_data)
{
+ struct bass_data *data = user_data;
const struct queue_entry *entry;
for (entry = queue_get_entries(assistants); entry;
@@ -2032,9 +2143,9 @@ static void bass_src_changed(uint8_t id, uint32_t bid, uint8_t state,
continue;
/* If BID is not set it may happen to be local stream so ignore
- * non-local assistants.
+ * non-local assistants unless their BID is also not set.
*/
- if (!bid && assistant->state != ASSISTANT_STATE_LOCAL)
+ if (!bid && assistant->bid)
continue;
if (state == BT_BASS_SYNC_INFO_RE) {
@@ -2066,21 +2177,34 @@ static void bass_src_changed(uint8_t id, uint32_t bid, uint8_t state,
break;
/* Match BIS index */
- if (bis & bis_sync)
+ if (bis & bis_sync) {
+ assistant->src_id = id;
assistant_set_state(assistant,
ASSISTANT_STATE_ACTIVE);
+ }
break;
case BT_BASS_BIG_ENC_STATE_DEC:
/* Only handle assistant objects that
* have requested a Broadcast Code
*/
- if (assistant->state != ASSISTANT_STATE_REQUESTING)
+ if (assistant->state != ASSISTANT_STATE_REQUESTING &&
+ assistant->state != ASSISTANT_STATE_LOCAL)
break;
/* Match BIS index */
- if (bis & bis_sync)
+ if (bis & bis_sync) {
+ assistant->src_id = id;
+
+ if (assistant->state ==
+ ASSISTANT_STATE_LOCAL) {
+ assistant_add_src(assistant, data->bass,
+ id);
+ break;
+ }
+
assistant_set_state(assistant,
ASSISTANT_STATE_ACTIVE);
+ }
break;
default:
continue;
--
2.54.0
^ permalink raw reply related
* [PATCH v1] Bluetooth: MGMT: Fix backward compatibility with userspace
From: Luiz Augusto von Dentz @ 2026-06-02 20:56 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bluetoothd has a bug with makes it send extra bytes as part of
MGMT_OP_ADD_EXT_ADV_DATA which are now being checked to be the
exact the expected length, relax this so only when the expected
length is greater than the data length to cause an error since
that would result in accessing invalid memory, otherwise just
ignore the extra bytes.
Link: https://lore.kernel.org/linux-bluetooth/20260602204749.210857-1-luiz.dentz@gmail.com/T/#u
Fixes: d3f7d17960ed ("Bluetooth: MGMT: validate Add Extended Advertising Data length")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/mgmt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index de5bd6b637b2..8e13af77d694 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -9114,8 +9114,9 @@ static int add_ext_adv_data(struct sock *sk, struct hci_dev *hdev, void *data,
BT_DBG("%s", hdev->name);
- expected_len = struct_size(cp, data, cp->adv_data_len + cp->scan_rsp_len);
- if (expected_len != data_len)
+ expected_len = struct_size(cp, data, cp->adv_data_len +
+ cp->scan_rsp_len);
+ if (expected_len > data_len)
return mgmt_cmd_status(sk, hdev->id, MGMT_OP_ADD_EXT_ADV_DATA,
MGMT_STATUS_INVALID_PARAMS);
--
2.54.0
^ permalink raw reply related
* [PATCH BlueZ v1] advertising: Fix sending extra bytes with MGMT_OP_ADD_EXT_ADV_DATA
From: Luiz Augusto von Dentz @ 2026-06-02 20:47 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
MGMT_OP_ADD_EXT_ADV_DATA expects the command to be of size of
struct mgmt_cp_add_ext_adv_data not mgmt_cp_add_advertising.
---
src/advertising.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/advertising.c b/src/advertising.c
index c8b00a887911..1ed09c902b4b 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1498,8 +1498,7 @@ static void add_adv_params_callback(uint8_t status, uint16_t length,
}
}
- param_len = sizeof(struct mgmt_cp_add_advertising) + adv_data_len +
- scan_rsp_len;
+ param_len = sizeof(*cp) + adv_data_len + scan_rsp_len;
cp = malloc0(param_len);
if (!cp) {
--
2.54.0
^ permalink raw reply related
* [syzbot] Monthly bluetooth report (Jun 2026)
From: syzbot @ 2026-06-02 20:32 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello bluetooth maintainers/developers,
This is a 31-day syzbot report for the bluetooth subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/bluetooth
During the period, 4 new issues were detected and 0 were fixed.
In total, 27 issues are still open and 102 have already been fixed.
There are also 8 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 9301 Yes WARNING in call_timer_fn
https://syzkaller.appspot.com/bug?extid=6fb78d577e89e69602f9
<2> 564 Yes WARNING: ODEBUG bug in hci_release_dev (2)
https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a
<3> 367 No WARNING in l2cap_chan_del
https://syzkaller.appspot.com/bug?extid=3272785b7a1fc9b510f6
<4> 345 Yes KASAN: wild-memory-access Read in l2cap_connect_cfm
https://syzkaller.appspot.com/bug?extid=0e4ebcc970728e056324
<5> 203 Yes KASAN: slab-use-after-free Read in l2cap_sock_new_connection_cb
https://syzkaller.appspot.com/bug?extid=cdae834448ec8c3602fe
<6> 111 Yes INFO: task hung in hci_cmd_sync_clear (3)
https://syzkaller.appspot.com/bug?extid=217e3f1283cafe80586e
<7> 97 Yes KASAN: slab-use-after-free Read in l2cap_sock_ready_cb (2)
https://syzkaller.appspot.com/bug?extid=9265e754091c2d27ea29
<8> 33 No WARNING: held lock freed in bt_accept_dequeue
https://syzkaller.appspot.com/bug?extid=4c5f0c6f8cc60159bdbf
<9> 165 Yes KASAN: slab-use-after-free Read in bt_accept_unlink
https://syzkaller.appspot.com/bug?extid=a1595e656a83ea5b78eb
<10> 91 Yes general protection fault in l2cap_chan_timeout (3)
https://syzkaller.appspot.com/bug?extid=f0908ddc8b64b86e81f2
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH] Bluetooth: MGMT: validate Add Extended Advertising Data length
From: Luiz Augusto von Dentz @ 2026-06-02 20:17 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Daniel Winkler, linux-bluetooth, linux-kernel
In-Reply-To: <20260515143819.1157807-1-michael.bommarito@gmail.com>
Hi,
On Fri, May 15, 2026 at 10:38 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,
> with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler
> then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy
> cp->data, but it never checks that those bytes are part of the mgmt
> command payload.
>
> A short command can therefore make add_ext_adv_data() pass an
> out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond
> the command buffer are addressable, they can also be copied into the
> advertising instance as scan response data, where the caller can read
> them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires
> CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte
> slab-out-of-bounds read.
>
> Reject commands whose length does not match the fixed header plus both
> advertising data lengths before parsing cp->data.
>
> Fixes: 12410572833a ("Bluetooth: Break add adv into two mgmt commands")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> net/bluetooth/mgmt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index b05bb380e5f8..de5bd6b637b2 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -9110,9 +9110,15 @@ static int add_ext_adv_data(struct sock *sk, struct hci_dev *hdev, void *data,
> struct adv_info *adv_instance;
> int err = 0;
> struct mgmt_pending_cmd *cmd;
> + u16 expected_len;
>
> BT_DBG("%s", hdev->name);
>
> + expected_len = struct_size(cp, data, cp->adv_data_len + cp->scan_rsp_len);
> + if (expected_len != data_len)
> + return mgmt_cmd_status(sk, hdev->id, MGMT_OP_ADD_EXT_ADV_DATA,
> + MGMT_STATUS_INVALID_PARAMS);
So it appears this was never tested with the likes of
bluetoothd/bluetoothctl> advertise on:
bluetoothd[40]: @ MGMT Command: Add Extende.. {0x0001} [hci0] 16:04:53.318270
Instance: 1
Advertising data length: 3
Advertising Data[3]:
02 01 06 ...
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Scan response length: 0
00 00 00 00 00 00 00 00 ........
<- Extra bytes
@ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0] 16:04:53.318287
Add Extended Advertising Data (0x0055)
Status: Invalid Parameters (0x0d)
That is probably a bug in bluetoothd but it breaks backward compatibility.
> hci_dev_lock(hdev);
>
> adv_instance = hci_find_adv_instance(hdev, cp->instance);
> --
> 2.53.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v5 08/16] test-runner: use virtio-serial for implementing -u device forwarding
From: Luiz Augusto von Dentz @ 2026-06-02 20:10 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <81837f88d2bc467cb3b188fbcebda0b395f5b689.camel@iki.fi>
Hi Pauli,
On Tue, Jun 2, 2026 at 4:03 PM Pauli Virtanen <pav@iki.fi> wrote:
>
> ti, 2026-06-02 kello 19:51 +0000, Pauli Virtanen kirjoitti:
> > Hi Luiz,
> >
> > ti, 2026-06-02 kello 15:35 -0400, Luiz Augusto von Dentz kirjoitti:
> > > Hi Pauli,
> > >
> > > On Wed, May 13, 2026 at 12:48 PM Pauli Virtanen <pav@iki.fi> wrote:
> > > >
> > > > Using pci-serial to forward eg. btvirt sockets is unreliable, as
> > > > qemu or
> > > > kernel seems to be sometimes dropping part of the sent data or
> > > > insert
> > > > spurious \0 bytes, leading to sporadic errors like:
> > > >
> > > > kernel: Bluetooth: hci0: command 0x0c52 tx timeout
> > > > kernel: Bluetooth: hci0: Opcode 0x0c52 failed: -110
> > > > btvirt: packet error, unknown type: 0
> > > >
> > > > This appears to occur most often when host system is under load,
> > > > e.g.
> > > > due to multiple test-runners running at the same time. The
> > > > problem
> > > > is
> > > > not specific to btvirt, but seems to be in the qemu serial device
> > > > layer
> > > > vs. kernel interaction.
> > > >
> > > > Change test-runner to use virtserialport to forward the btvirt
> > > > connection inside the VM, as virtio-serial doesn't appear to have
> > > > these
> > > > problems.
> > > > ---
> > > > tools/test-runner.c | 13 +++++++++----
> > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/tools/test-runner.c b/tools/test-runner.c
> > > > index b3e0b0cfe..0e3bfb8b7 100644
> > > > --- a/tools/test-runner.c
> > > > +++ b/tools/test-runner.c
> > > > @@ -306,7 +306,7 @@ static void start_qemu(void)
> > > > testargs);
> > > >
> > > > argv = alloca(sizeof(qemu_argv) +
> > > > - (sizeof(char *) * (6 + (num_devs * 4))) +
> > > > + (sizeof(char *) * (8 + (num_devs * 4))) +
> > > > (sizeof(char *) * (usb_dev ? 4 : 0)) +
> > > > (sizeof(char *) * num_extra_opts));
> > > > memcpy(argv, qemu_argv, sizeof(qemu_argv));
> > > > @@ -330,14 +330,19 @@ static void start_qemu(void)
> > > > argv[pos++] = "-append";
> > > > argv[pos++] = (char *) cmdline;
> > > >
> > > > + if (num_devs) {
> > > > + argv[pos++] = "-device";
> > > > + argv[pos++] = "virtio-serial";
> > > > + }
> > > > +
> > > > for (i = 0; i < num_devs; i++) {
> > > > char *chrdev, *serdev;
> > > >
> > > > chrdev = alloca(48 + strlen(device_path));
> > > > sprintf(chrdev, "socket,path=%s,id=bt%d",
> > > > device_path, i);
> > > >
> > > > - serdev = alloca(48);
> > > > - sprintf(serdev, "pci-serial,chardev=bt%d", i);
> > > > + serdev = alloca(64);
> > > > + sprintf(serdev,
> > > > "virtconsole,chardev=bt%d,name=bt.%d", i, i);
> > > >
> > > > argv[pos++] = "-chardev";
> > > > argv[pos++] = chrdev;
> > > > @@ -910,7 +915,7 @@ static void run_command(char *cmdname, char
> > > > *home)
> > > > }
> > > >
> > > > if (num_devs) {
> > > > - const char *node = "/dev/ttyS1";
> > > > + const char *node = "/dev/hvc0";
> > >
> > > Im getting and error with these changes:
> > >
> > > Attaching BR/EDR controller to /dev/hvc0
> > > Failed to open serial port: No such file or directory
> > >
> > > I tried adding the kernel config options but it didn't make any
> > > difference.
> >
> > We have test-runner with this patch in Pipewire CI, and it is working
> >
> > https://gitlab.freedesktop.org/pipewire/pipewire/-/jobs/101256448
> >
> > on Fedora 44 + Qemu 10.2.2. Kernel configuration is here:
> >
> > https://github.com/pv/bluez-test-functional-kernel/blob/main/tester.config
> >
> > I've also used with this for USB redirection.
>
> Also, the exact kernel image we are using built from that config is
> here:
>
> https://github.com/pv/bluez-test-functional-kernel/releases/tag/2026-05-08.1
>
> at bluez 07b6fc156348bb515ac0a876d49644312c9476d6 I can then do
>
> $ ./emulator/btvirt -s &
> $ ./tools/test-runner -u/tmp/bt-server-bredrle -k bzImage -- bash
> ...
> Attachment of devices requested
> Attaching BR/EDR controller to /dev/hvc0
> Switched line discipline from 0 to 15
> Device index 0 attached
> Running command bash
Seem that CONFIG_VIRTIO_CONSOLE was not enabled for some reason, once
I enabled it works as intended.
> >
> > Not sure what is different for you, do you get any virtio serial
> > devices from the virtconsole?
> >
> > >
> > > > unsigned int basic_flags, extra_flags;
> > > >
> > > > printf("Attaching BR/EDR controller to %s\n",
> > > > node);
> > > > --
> > > > 2.54.0
> > > >
> > > >
> > >
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v5 08/16] test-runner: use virtio-serial for implementing -u device forwarding
From: Pauli Virtanen @ 2026-06-02 20:03 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <132073b9a61db8dcd9c85f0b5787200a63a50604.camel@iki.fi>
ti, 2026-06-02 kello 19:51 +0000, Pauli Virtanen kirjoitti:
> Hi Luiz,
>
> ti, 2026-06-02 kello 15:35 -0400, Luiz Augusto von Dentz kirjoitti:
> > Hi Pauli,
> >
> > On Wed, May 13, 2026 at 12:48 PM Pauli Virtanen <pav@iki.fi> wrote:
> > >
> > > Using pci-serial to forward eg. btvirt sockets is unreliable, as
> > > qemu or
> > > kernel seems to be sometimes dropping part of the sent data or
> > > insert
> > > spurious \0 bytes, leading to sporadic errors like:
> > >
> > > kernel: Bluetooth: hci0: command 0x0c52 tx timeout
> > > kernel: Bluetooth: hci0: Opcode 0x0c52 failed: -110
> > > btvirt: packet error, unknown type: 0
> > >
> > > This appears to occur most often when host system is under load,
> > > e.g.
> > > due to multiple test-runners running at the same time. The
> > > problem
> > > is
> > > not specific to btvirt, but seems to be in the qemu serial device
> > > layer
> > > vs. kernel interaction.
> > >
> > > Change test-runner to use virtserialport to forward the btvirt
> > > connection inside the VM, as virtio-serial doesn't appear to have
> > > these
> > > problems.
> > > ---
> > > tools/test-runner.c | 13 +++++++++----
> > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/tools/test-runner.c b/tools/test-runner.c
> > > index b3e0b0cfe..0e3bfb8b7 100644
> > > --- a/tools/test-runner.c
> > > +++ b/tools/test-runner.c
> > > @@ -306,7 +306,7 @@ static void start_qemu(void)
> > > testargs);
> > >
> > > argv = alloca(sizeof(qemu_argv) +
> > > - (sizeof(char *) * (6 + (num_devs * 4))) +
> > > + (sizeof(char *) * (8 + (num_devs * 4))) +
> > > (sizeof(char *) * (usb_dev ? 4 : 0)) +
> > > (sizeof(char *) * num_extra_opts));
> > > memcpy(argv, qemu_argv, sizeof(qemu_argv));
> > > @@ -330,14 +330,19 @@ static void start_qemu(void)
> > > argv[pos++] = "-append";
> > > argv[pos++] = (char *) cmdline;
> > >
> > > + if (num_devs) {
> > > + argv[pos++] = "-device";
> > > + argv[pos++] = "virtio-serial";
> > > + }
> > > +
> > > for (i = 0; i < num_devs; i++) {
> > > char *chrdev, *serdev;
> > >
> > > chrdev = alloca(48 + strlen(device_path));
> > > sprintf(chrdev, "socket,path=%s,id=bt%d",
> > > device_path, i);
> > >
> > > - serdev = alloca(48);
> > > - sprintf(serdev, "pci-serial,chardev=bt%d", i);
> > > + serdev = alloca(64);
> > > + sprintf(serdev,
> > > "virtconsole,chardev=bt%d,name=bt.%d", i, i);
> > >
> > > argv[pos++] = "-chardev";
> > > argv[pos++] = chrdev;
> > > @@ -910,7 +915,7 @@ static void run_command(char *cmdname, char
> > > *home)
> > > }
> > >
> > > if (num_devs) {
> > > - const char *node = "/dev/ttyS1";
> > > + const char *node = "/dev/hvc0";
> >
> > Im getting and error with these changes:
> >
> > Attaching BR/EDR controller to /dev/hvc0
> > Failed to open serial port: No such file or directory
> >
> > I tried adding the kernel config options but it didn't make any
> > difference.
>
> We have test-runner with this patch in Pipewire CI, and it is working
>
> https://gitlab.freedesktop.org/pipewire/pipewire/-/jobs/101256448
>
> on Fedora 44 + Qemu 10.2.2. Kernel configuration is here:
>
> https://github.com/pv/bluez-test-functional-kernel/blob/main/tester.config
>
> I've also used with this for USB redirection.
Also, the exact kernel image we are using built from that config is
here:
https://github.com/pv/bluez-test-functional-kernel/releases/tag/2026-05-08.1
at bluez 07b6fc156348bb515ac0a876d49644312c9476d6 I can then do
$ ./emulator/btvirt -s &
$ ./tools/test-runner -u/tmp/bt-server-bredrle -k bzImage -- bash
...
Attachment of devices requested
Attaching BR/EDR controller to /dev/hvc0
Switched line discipline from 0 to 15
Device index 0 attached
Running command bash
>
> Not sure what is different for you, do you get any virtio serial
> devices from the virtconsole?
>
> >
> > > unsigned int basic_flags, extra_flags;
> > >
> > > printf("Attaching BR/EDR controller to %s\n",
> > > node);
> > > --
> > > 2.54.0
> > >
> > >
> >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox