* RE: [BlueZ] tools/iso-tester: fix GIOChannel refcounting
From: bluez.test.bot @ 2026-07-20 20:35 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <77c23b3b0b0b0be0ce52e5718f88f8723dabf7ee.1784571951.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 824 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=1131086
---Test result---
Test Summary:
CheckPatch PASS 1.43 seconds
GitLint PASS 0.32 seconds
BuildEll PASS 20.37 seconds
BluezMake PASS 498.03 seconds
CheckSmatch PASS 296.18 seconds
bluezmakeextell PASS 95.09 seconds
IncrementalBuild PASS 496.49 seconds
ScanBuild PASS 882.20 seconds
https://github.com/bluez/bluez/pull/2334
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Bluetooth: btusb: missing device ID 13d3:3626 (Realtek RTL8851BE, IMC Networks rebrand)
From: Daniel Alonso Briones @ 2026-07-20 22:59 UTC (permalink / raw)
To: linux-bluetooth
Hi,
My Bluetooth radio (part of a Realtek RTL8851BE wifi+BT combo module,
OEM-branded "IMC Networks") is not recognized by btusb's device table,
so the Realtek firmware never loads and the radio does not work at the
RF level at all (confirmed: neither scanning from the device nor being
scanned by other devices detects anything).
Device details (lsusb -v):
idVendor 0x13d3 IMC Networks
idProduct 0x3626 Bluetooth Radio
bcdDevice 0.00
iManufacturer 1 Realtek
iProduct 2 Bluetooth Radio
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
Kernel log on enumeration:
usb 7-1: New USB device found, idVendor=13d3, idProduct=3626, bcdDevice= 0.00
usb 7-1: Product: Bluetooth Radio
usb 7-1: Manufacturer: Realtek
This looks like the same situation as 13d3:3600/13d3:3601 (RTL8851BE,
added in commit adding "Bluetooth: btusb: Add RTL8851BE device
0x13d3:0x3601"), just a different OEM USB ID for the same chip.
Would it be possible to add:
{ USB_DEVICE(0x13d3, 0x3626), .driver_info = BTUSB_REALTEK },
to the device table in drivers/bluetooth/btusb.c, next to the existing
0x13d3:0x3600/0x3601 entries?
Happy to test a patch if needed
Thanks,
Daniel
^ permalink raw reply
* [syzbot] [bluetooth?] KASAN: null-ptr-deref Read in l2cap_chan_hold_unless_zero
From: syzbot @ 2026-07-20 23:56 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: e22254e9ddd8 Merge tag 'xfs-fixes-7.2-rc4' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d46789580000
kernel config: https://syzkaller.appspot.com/x/.config?x=48ef5c5c0f192153
dashboard link: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17b434b9580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17d46789580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-e22254e9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c69a30d7d78f/vmlinux-e22254e9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f15a346cc7e1/bzImage-e22254e9.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline]
BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
BUG: KASAN: null-ptr-deref in refcount_read include/linux/refcount.h:170 [inline]
BUG: KASAN: null-ptr-deref in __refcount_add_not_zero include/linux/refcount.h:176 [inline]
BUG: KASAN: null-ptr-deref in __refcount_inc_not_zero include/linux/refcount.h:317 [inline]
BUG: KASAN: null-ptr-deref in refcount_inc_not_zero include/linux/refcount.h:335 [inline]
BUG: KASAN: null-ptr-deref in kref_get_unless_zero include/linux/kref.h:133 [inline]
BUG: KASAN: null-ptr-deref in l2cap_chan_hold_unless_zero+0x80/0x290 net/bluetooth/l2cap_core.c:511
Read of size 4 at addr 0000000000000008 by task syz.0.158/6397
CPU: 2 UID: 0 PID: 6397 Comm: syz.0.158 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:186 [inline]
kasan_check_range+0x10f/0x1e0 mm/kasan/generic.c:200
instrument_atomic_read include/linux/instrumented.h:82 [inline]
atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
refcount_read include/linux/refcount.h:170 [inline]
__refcount_add_not_zero include/linux/refcount.h:176 [inline]
__refcount_inc_not_zero include/linux/refcount.h:317 [inline]
refcount_inc_not_zero include/linux/refcount.h:335 [inline]
kref_get_unless_zero include/linux/kref.h:133 [inline]
l2cap_chan_hold_unless_zero+0x80/0x290 net/bluetooth/l2cap_core.c:511
l2cap_sock_cleanup_listen+0x8a/0x4d0 net/bluetooth/l2cap_sock.c:1535
l2cap_sock_release+0x69/0x280 net/bluetooth/l2cap_sock.c:1480
__sock_release+0xb3/0x260 net/socket.c:710
sock_close+0x1c/0x30 net/socket.c:1501
__fput+0x3ff/0xb50 fs/file_table.c:512
task_work_run+0x150/0x240 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:70 [inline]
exit_to_user_mode_loop+0x1d8/0x6f0 kernel/entry/common.c:101
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x666/0x870 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3758d9de99
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff659f88f8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00007f3759027da0 RCX: 00007f3758d9de99
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007f3759027da0 R08: 0000000000000006 R09: 0000000000000000
R10: 00007f3759027cb0 R11: 0000000000000246 R12: 0000000000046482
R13: 00007f375902609c R14: 00000000000461ac R15: 00007f3759026090
</TASK>
==================================================================
---
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.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH] Bluetooth: btusb: Add ID 0b05:1825 for ASUS QCA ROME adapter
From: Edgard Lopes @ 2026-07-21 2:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Luiz Augusto von Dentz
The Bluetooth radio of the ASUS combo WiFi/BT card based on QCA6174
(e.g. bundled with ASUS motherboards / PCE-AC55BT) is a QCA ROME
device rebranded under the ASUS vendor ID:
idVendor=0x0b05, idProduct=0x1825, bcdDevice=0.01
bDeviceClass=e0 Sub=01 Prot=01 (full speed, MxPS=64)
Both interfaces Cls=e0(wlcon) Sub=01 Prot=01, driven by btusb
Without the quirk, btusb treats it as a generic adapter and never
loads the QCA rampatch firmware, leaving the device running its bare
ROM firmware. In that state SCO/eSCO audio is broken: the controller
delivers malformed packets which the kernel drops ("Bluetooth: hci0:
corrupted SCO packet"), so HFP/HSP microphone input never works, and
the kernel also logs "unexpected event for opcode 0x2005" during LE
operations.
With this entry the device is set up as QCA ROME:
Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome
0x302 build 0x111
Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
after which eSCO audio works in both directions with zero errors
(verified with HFP against JBL Live 770NC and other headsets).
The driver_info flags match the sibling QCA6174 entry 0cf3:e300.
Signed-off-by: Edgard Lopes Voos <edgardlv@gmail.com>
---
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -259,6 +259,8 @@
{ USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 },
/* QCA ROME chipset */
+ { USB_DEVICE(0x0b05, 0x1825), .driver_info = BTUSB_QCA_ROME |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0cf3, 0x535b), .driver_info = BTUSB_QCA_ROME |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0cf3, 0xe007), .driver_info = BTUSB_QCA_ROME |
^ permalink raw reply
* [PATCH V7] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: Sherry Sun (OSS) @ 2026-07-21 3:04 UTC (permalink / raw)
To: amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz
Cc: imx, linux-kernel, linux-bluetooth, sherry.sun
From: Sherry Sun <sherry.sun@nxp.com>
Power supply to the M.2 Bluetooth device attached to the host using M.2
connector is controlled using the 'uart' pwrseq device. So add support
for getting the pwrseq device if the OF graph link is present.
Once obtained, pwrseq_power_on() is called to power up the M.2 Bluetooth
card. The power sequencer descriptor is obtained via pwrseq_get() with
the UART controller device (serdev->ctrl->dev), since the OF graph
link is defined on the UART controller node.
Also add the explicit pwrseq_put() call in all exit paths, pwrseq_put()
already calls pwrseq_power_off() internally, so no separate
pwrseq_power_off() call is needed.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
Changes in V7:
1. Seperate this Bluetooth patch from the V6 M.2 patch set so that it
can be applied directly to bluetooth-next tree, no code change.
https://lore.kernel.org/all/20260713023435.235765-1-sherry.sun@oss.nxp.com/
---
drivers/bluetooth/btnxpuart.c | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index 0bb300eef157..81a11ac05114 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -9,6 +9,8 @@
#include <linux/serdev.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/pwrseq/consumer.h>
#include <linux/skbuff.h>
#include <linux/unaligned.h>
#include <linux/firmware.h>
@@ -211,6 +213,7 @@ struct btnxpuart_dev {
struct ps_data psdata;
struct btnxpuart_data *nxp_data;
+ struct pwrseq_desc *pwrseq;
struct reset_control *pdn;
struct hci_uart hu;
};
@@ -1872,11 +1875,26 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
return err;
}
+ if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
+ struct pwrseq_desc *pwrseq;
+
+ pwrseq = pwrseq_get(&serdev->ctrl->dev, "uart");
+ if (IS_ERR(pwrseq))
+ return dev_err_probe(&serdev->dev, PTR_ERR(pwrseq),
+ "failed to get pwrseq\n");
+
+ nxpdev->pwrseq = pwrseq;
+ err = pwrseq_power_on(pwrseq);
+ if (err)
+ goto err_pwrseq_put;
+ }
+
/* Initialize and register HCI device */
hdev = hci_alloc_dev();
if (!hdev) {
dev_err(&serdev->dev, "Can't allocate HCI device\n");
- return -ENOMEM;
+ err = -ENOMEM;
+ goto err_pwrseq_put;
}
reset_control_deassert(nxpdev->pdn);
@@ -1907,13 +1925,16 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
if (bacmp(&ba, BDADDR_ANY))
hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
- if (hci_register_dev(hdev) < 0) {
+ err = hci_register_dev(hdev);
+ if (err < 0) {
dev_err(&serdev->dev, "Can't register HCI device\n");
goto probe_fail;
}
- if (ps_setup(hdev))
+ if (ps_setup(hdev)) {
+ err = -ENODEV;
goto probe_fail_unregister;
+ }
hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
nxp_coredump_notify);
@@ -1925,7 +1946,10 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
probe_fail:
reset_control_assert(nxpdev->pdn);
hci_free_dev(hdev);
- return -ENODEV;
+err_pwrseq_put:
+ if (nxpdev->pwrseq)
+ pwrseq_put(nxpdev->pwrseq);
+ return err;
}
static void nxp_serdev_remove(struct serdev_device *serdev)
@@ -1952,6 +1976,8 @@ static void nxp_serdev_remove(struct serdev_device *serdev)
ps_cleanup(nxpdev);
hci_unregister_dev(hdev);
reset_control_assert(nxpdev->pdn);
+ if (nxpdev->pwrseq)
+ pwrseq_put(nxpdev->pwrseq);
hci_free_dev(hdev);
}
base-commit: 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
--
2.50.1
^ permalink raw reply related
* RE: Bluetooth: btusb: Add ID 0b05:1825 for ASUS QCA ROME adapter
From: bluez.test.bot @ 2026-07-21 3:49 UTC (permalink / raw)
To: linux-bluetooth, edgardlv
In-Reply-To: <CACUvvBVT=iVA4GjCHOwxdD9R6ukVmdM-mfr0u9NBfua1cBsUNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 552 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: drivers/bluetooth/btusb.c:259
error: drivers/bluetooth/btusb.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
* RE: [V7] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: bluez.test.bot @ 2026-07-21 4:13 UTC (permalink / raw)
To: linux-bluetooth, sherry.sun
In-Reply-To: <20260721030458.1160824-1-sherry.sun@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1181 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=1131272
---Test result---
Test Summary:
CheckPatch PASS 0.63 seconds
VerifyFixes PASS 2.25 seconds
VerifySignedoff PASS 1.70 seconds
GitLint PASS 2.26 seconds
SubjectPrefix PASS 0.88 seconds
BuildKernel PASS 28.61 seconds
CheckAllWarning PASS 30.39 seconds
CheckSparse PASS 29.95 seconds
BuildKernel32 PASS 26.25 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 502.94 seconds
IncrementalBuild PASS 25.15 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/467
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re:Re: Re: [PATCH v3] Bluetooth: HIDP: add missing length check for incoming frames
From: jiale yao @ 2026-07-21 5:54 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Tim Bird, Muhammad Bilal, Kees Cook,
Michael Bommarito, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZLmjDkAGX-mBaySPnxp-mh2bPXaNh=b=dZ8wq9yeS2wRQ@mail.gmail.com>
In hidp_recv_ctrl_frame() and hidp_recv_intr_frame(), skb->data[0] is
read without verifying that skb->len >= 1. A zero-length L2CAP PDU
delivered via the HIDP control or interrupt channel causes an
out-of-bounds read.
Use skb_pull_data(skb, 1) which combines the length check and pull
in one operation, matching the existing pattern in hidp_input_report()
and the fix in commit 6770d3a8acdf ("Bluetooth: bnep: reject short
frames before parsing") which addressed the same class of bug in BNEP.
Assisted-by: Claude:deepseek-v4-pro
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
net/bluetooth/hidp/core.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0e24c5e2955e..e29fe66f01d4 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -560,16 +560,18 @@ static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
static void hidp_recv_ctrl_frame(struct hidp_session *session,
struct sk_buff *skb)
{
- unsigned char hdr, type, param;
+ unsigned char *hdr;
+ unsigned char type, param;
int free_skb = 1;
BT_DBG("session %p skb %p len %u", session, skb, skb->len);
- hdr = skb->data[0];
- skb_pull(skb, 1);
+ hdr = skb_pull_data(skb, 1);
+ if (!hdr)
+ goto failed;
- type = hdr & HIDP_HEADER_TRANS_MASK;
- param = hdr & HIDP_HEADER_PARAM_MASK;
+ type = *hdr & HIDP_HEADER_TRANS_MASK;
+ param = *hdr & HIDP_HEADER_PARAM_MASK;
switch (type) {
case HIDP_TRANS_HANDSHAKE:
@@ -590,6 +592,7 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
break;
}
+failed:
if (free_skb)
kfree_skb(skb);
}
@@ -597,14 +600,15 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
static void hidp_recv_intr_frame(struct hidp_session *session,
struct sk_buff *skb)
{
- unsigned char hdr;
+ unsigned char *hdr;
BT_DBG("session %p skb %p len %u", session, skb, skb->len);
- hdr = skb->data[0];
- skb_pull(skb, 1);
+ hdr = skb_pull_data(skb, 1);
+ if (!hdr)
+ goto failed;
- if (hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
+ if (*hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
hidp_set_timer(session);
if (session->input)
@@ -616,9 +620,10 @@ static void hidp_recv_intr_frame(struct hidp_session *session,
BT_DBG("report len %d", skb->len);
}
} else {
- BT_DBG("Unsupported protocol header 0x%02x", hdr);
+ BT_DBG("Unsupported protocol header 0x%02x", *hdr);
}
+failed:
kfree_skb(skb);
}
--
2.34.1
At 2026-07-21 03:47:21, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>Hi,
>
>On Sun, Jul 19, 2026 at 1:38 AM jiale yao <19888972804@163.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>> In hidp_recv_ctrl_frame() and hidp_recv_intr_frame(), skb->data[0] is
>> read without verifying that skb->len >= 1. A zero-length L2CAP PDU
>> delivered via the HIDP control or interrupt channel causes an
>> out-of-bounds read.
>>
>> Use skb_pull_data(skb, 1) which combines the length check and pull
>> in one operation, matching the existing pattern in hidp_input_report()
>> and the fix in commit 6770d3a8acdf ("Bluetooth: bnep: reject short
>> frames before parsing") which addressed the same class of bug in BNEP.
>>
>> Assisted-by: Claude:deepseek-v4-pro
>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> ---
>> net/bluetooth/hidp/core.c | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
>> index 0e24c5e2955e..bb61602b02e1 100644
>> --- a/net/bluetooth/hidp/core.c
>> +++ b/net/bluetooth/hidp/core.c
>> @@ -560,16 +560,18 @@ static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
>> static void hidp_recv_ctrl_frame(struct hidp_session *session,
>> struct sk_buff *skb)
>> {
>> - unsigned char hdr, type, param;
>> + unsigned char *hdr;
>> + unsigned char type, param;
>> int free_skb = 1;
>>
>> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>>
>> - hdr = skb->data[0];
>> - skb_pull(skb, 1);
>> + hdr = skb_pull_data(skb, 1);
>> + if (!hdr)
>> + return;
>
>https://sashiko.dev/#/patchset/20260717153238.2002330-1-yaojiale02%40163.com
>
>It seems that by early returning we are leaking the skb.
>
>>
>> - type = hdr & HIDP_HEADER_TRANS_MASK;
>> - param = hdr & HIDP_HEADER_PARAM_MASK;
>> + type = *hdr & HIDP_HEADER_TRANS_MASK;
>> + param = *hdr & HIDP_HEADER_PARAM_MASK;
>>
>> switch (type) {
>> case HIDP_TRANS_HANDSHAKE:
>> @@ -597,14 +599,15 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
>> static void hidp_recv_intr_frame(struct hidp_session *session,
>> struct sk_buff *skb)
>> {
>> - unsigned char hdr;
>> + unsigned char *hdr;
>>
>> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>>
>> - hdr = skb->data[0];
>> - skb_pull(skb, 1);
>> + hdr = skb_pull_data(skb, 1);
>> + if (!hdr)
>> + return;
>>
>> - if (hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
>> + if (*hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
>> hidp_set_timer(session);
>>
>> if (session->input)
>> --
>> 2.34.1
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> At 2026-07-17 23:40:11, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>> >Hi,
>> >
>> >On Fri, Jul 17, 2026 at 11:33 AM Jiale Yao <yaojiale02@163.com> wrote:
>> >>
>> >> In hidp_recv_ctrl_frame() and hidp_recv_intr_frame(), skb->data[0] is
>> >> read without verifying that skb->len >= 1. A zero-length L2CAP PDU
>> >> delivered via the HIDP control or interrupt channel causes an
>> >> out-of-bounds read.
>> >>
>> >> Add pskb_may_pull(skb, 1) guards before both reads, matching the fix
>> >> in commit 6770d3a8acdf ("Bluetooth: bnep: reject short frames before
>> >> parsing") which addressed the same class of bug in BNEP.
>> >>
>> >> Assisted-by: Claude:deepseek-v4-pro
>> >> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> >> ---
>> >> net/bluetooth/hidp/core.c | 4 ++++
>> >> 1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
>> >> index 0e24c5e2955e..6c7da8aca732 100644
>> >> --- a/net/bluetooth/hidp/core.c
>> >> +++ b/net/bluetooth/hidp/core.c
>> >> @@ -565,6 +565,8 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
>> >>
>> >> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>> >>
>> >> + if (!pskb_may_pull(skb, 1))
>> >> + return;
>> >
>> >We can probably replace this with skb_pull_data.
>> >
>> >> hdr = skb->data[0];
>> >> skb_pull(skb, 1);
>> >>
>> >> @@ -601,6 +603,8 @@ static void hidp_recv_intr_frame(struct hidp_session *session,
>> >>
>> >> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>> >>
>> >> + if (!pskb_may_pull(skb, 1))
>> >> + return;
>> >
>> >Ditto.
>> >
>> >> hdr = skb->data[0];
>> >> skb_pull(skb, 1);
>> >>
>> >> --
>> >> 2.34.1
>> >>
>> >
>> >
>> >--
>> >Luiz Augusto von Dentz
>
>
>
>--
>Luiz Augusto von Dentz
^ permalink raw reply related
* [PATCH] Bluetooth: sco: Remove redundant mtu assignment in sco_conn_add()
From: Zhao Dongdong @ 2026-07-21 8:12 UTC (permalink / raw)
To: marcel, luiz.dentz; +Cc: linux-bluetooth, linux-kernel, Zhao Dongdong
From: Zhao Dongdong <zhaodongdong@kylinos.cn>
In sco_conn_add(), conn->mtu is first assigned hcon->mtu
unconditionally, then immediately overwritten by the subsequent
if/else block which either assigns hcon->mtu again (when
hcon->mtu > 0) or sets it to 60. The first assignment is dead
code and can be safely removed.
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
---
net/bluetooth/sco.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index c05f79b7aa31..e4f0f6fb01de 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -212,7 +212,6 @@ static struct sco_conn *sco_conn_add(struct hci_conn *hcon)
hcon->sco_data = conn;
conn->hcon = hcon;
- conn->mtu = hcon->mtu;
if (hcon->mtu > 0)
conn->mtu = hcon->mtu;
--
2.25.1
^ permalink raw reply related
* [PATCH BlueZ v5 0/2] RAP: streamline session handling, reflector setup
From: Naga Bhavani Akella @ 2026-07-21 8:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
This series removes RAS accessed callback bridge and
switches RAP users to direct session lookup.
The first patch refactors the shared RAP layer by introducing explicit
attachment/disconnection helpers, adding bt_rap_get_session(), and
using session lookup directly from the RAS GATT server callbacks.
With all users migrated, the accessed-notification bridge and its public
registration APIs are removed.
The second patch updates the ranging RAP profile accordingly.
Reflector setup is consolidated into a dedicated helper, D-Bus registration
state is tracked explicitly, cleanup is centralized in rap_data_free(), and
RAS accessed callback handling is dropped.
Naga Bhavani Akella (2):
rap: use session lookup for RAS operations
profiles: centralize reflector setup
profiles/ranging/rap.c | 137 +++++++++++++++++++++++++----------------
src/shared/rap.c | 107 ++++++++++++++++++++++++++++++--
src/shared/rap.h | 2 +
3 files changed, 189 insertions(+), 57 deletions(-)
--
^ permalink raw reply
* [PATCH BlueZ v5 1/2] rap: use session lookup for RAS operations
From: Naga Bhavani Akella @ 2026-07-21 8:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260721084121.688467-1-naga.akella@oss.qualcomm.com>
Store disconnect information in RAP state and
centralize attachment handling through dedicated helpers.
Add bt_rap_get_session() and use it from all RAS
GATT server callbacks instead of the previous accessed
notification bridge. As part of the cleanup,
remove the accessed callback registration APIs,
related notification code, and the unused timeout.h include
---
src/shared/rap.c | 107 +++++++++++++++++++++++++++++++++++++++++++++--
src/shared/rap.h | 2 +
2 files changed, 105 insertions(+), 4 deletions(-)
diff --git a/src/shared/rap.c b/src/shared/rap.c
index dfb272d3a..962b84240 100644
--- a/src/shared/rap.c
+++ b/src/shared/rap.c
@@ -19,7 +19,6 @@
#include "src/shared/queue.h"
#include "src/shared/util.h"
-#include "src/shared/timeout.h"
#include "src/shared/att.h"
#include "src/shared/gatt-db.h"
#include "src/shared/gatt-server.h"
@@ -291,6 +290,7 @@ struct bt_rap {
struct bt_att *att;
unsigned int idle_id;
+ unsigned int disconn_id;
struct queue *notify;
struct queue *pending;
@@ -564,6 +564,40 @@ static void rap_detached(void *data, void *user_data)
cb->detached(rap, cb->user_data);
}
+static void rap_attached(void *data, void *user_data)
+{
+ struct bt_rap_cb *cb = data;
+ struct bt_rap *rap = user_data;
+
+ if (!cb->attached)
+ return;
+
+ cb->attached(rap, cb->user_data);
+}
+
+static void rap_disconnected(int err, void *user_data)
+{
+ struct bt_rap *rap = user_data;
+
+ rap->disconn_id = 0;
+
+ bt_rap_detach(rap);
+}
+
+static void rap_attach_att(struct bt_rap *rap, struct bt_att *att)
+{
+ if (rap->disconn_id) {
+ if (att == bt_rap_get_att(rap))
+ return;
+ bt_att_unregister_disconnect(rap->att, rap->disconn_id);
+ }
+
+ rap->att = att;
+ rap->disconn_id = bt_att_register_disconnect(rap->att,
+ rap_disconnected,
+ rap, NULL);
+}
+
void bt_rap_detach(struct bt_rap *rap)
{
if (!queue_remove(sessions, rap))
@@ -573,6 +607,9 @@ void bt_rap_detach(struct bt_rap *rap)
bt_gatt_client_unref(rap->client);
rap->client = NULL;
+ bt_att_unregister_disconnect(rap->att, rap->disconn_id);
+ rap->att = NULL;
+
queue_foreach(bt_rap_cbs, rap_detached, rap);
}
@@ -653,6 +690,29 @@ struct bt_att *bt_rap_get_att(struct bt_rap *rap)
return bt_gatt_client_get_att(rap->client);
}
+struct bt_rap *bt_rap_get_session(struct bt_att *att, struct gatt_db *db)
+{
+ const struct queue_entry *entry;
+ struct bt_rap *rap;
+
+ for (entry = queue_get_entries(sessions); entry; entry = entry->next) {
+ struct bt_rap *rap = entry->data;
+
+ if (att == bt_rap_get_att(rap))
+ return rap;
+ }
+
+ rap = bt_rap_new(db, NULL);
+ if (!rap)
+ return NULL;
+
+ rap->att = att;
+
+ bt_rap_attach(rap, NULL);
+
+ return rap;
+}
+
struct bt_rap *bt_rap_ref(struct bt_rap *rap)
{
if (!rap)
@@ -729,6 +789,7 @@ static void ras_features_read_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ struct ras *ras = user_data;
/*
* Feature mask: bits 0-2 set:
* - Real-time ranging
@@ -737,6 +798,9 @@ static void ras_features_read_cb(struct gatt_db_attribute *attrib,
*/
uint8_t value[4] = { 0x01, 0x00, 0x00, 0x00 };
+ if (ras)
+ bt_rap_get_session(att, ras->rapdb->db);
+
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -745,6 +809,11 @@ static void ras_ondemand_read_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ struct ras *ras = user_data;
+
+ if (ras)
+ bt_rap_get_session(att, ras->rapdb->db);
+
/* No static read data – on‑demand data is pushed via
* notifications
*/
@@ -761,6 +830,11 @@ static void ras_control_point_write_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ struct ras *ras = user_data;
+
+ if (ras)
+ bt_rap_get_session(att, ras->rapdb->db);
+
/* Control point handler - implementation TBD */
}
@@ -770,9 +844,13 @@ static void ras_data_ready_read_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ struct ras *ras = user_data;
uint16_t counter = 0;
uint8_t value[2];
+ if (ras)
+ bt_rap_get_session(att, ras->rapdb->db);
+
put_le16(counter, value);
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -783,8 +861,12 @@ static void ras_data_overwritten_read_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ struct ras *ras = user_data;
uint8_t value[2] = { 0x00, 0x00 };
+ if (ras)
+ bt_rap_get_session(att, ras->rapdb->db);
+
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -806,6 +888,8 @@ static void ras_ranging_data_ccc_write_cb(struct gatt_db_attribute *attrib,
return;
}
+ bt_rap_get_session(att, ras->rapdb->db);
+
if (offset) {
gatt_db_attribute_write_result(attrib, id,
BT_ATT_ERROR_INVALID_OFFSET);
@@ -2795,27 +2879,42 @@ bool bt_rap_attach(struct bt_rap *rap, struct bt_gatt_client *client)
{
bt_uuid_t uuid;
+ if (queue_find(sessions, NULL, rap)) {
+ if (client && !rap->client)
+ goto clone;
+ return true;
+ }
+
if (!sessions)
sessions = queue_new();
queue_push_tail(sessions, rap);
- if (!client)
+ queue_foreach(bt_rap_cbs, rap_attached, rap);
+
+ if (!client) {
+ if (rap->att)
+ rap_attach_att(rap, rap->att);
return true;
+ }
if (rap->client)
return false;
+clone:
rap->client = bt_gatt_client_clone(client);
if (!rap->client)
return false;
+ rap_attach_att(rap, bt_gatt_client_get_att(client));
+
bt_gatt_client_idle_register(rap->client, rap_idle, rap, NULL);
bt_uuid16_create(&uuid, RAS_UUID16);
- gatt_db_foreach_service(rap->rrapdb->db, &uuid,
- foreach_rap_service, rap);
+ if (rap->rrapdb)
+ gatt_db_foreach_service(rap->rrapdb->db, &uuid,
+ foreach_rap_service, rap);
return true;
}
diff --git a/src/shared/rap.h b/src/shared/rap.h
index 5582635e6..a44831e6e 100644
--- a/src/shared/rap.h
+++ b/src/shared/rap.h
@@ -15,6 +15,7 @@
struct bt_rap;
struct gatt_db;
struct bt_gatt_client;
+struct bt_att;
/* Channel Sounding Events */
struct bt_rap_hci_cs_options {
@@ -171,6 +172,7 @@ bool bt_rap_attach(struct bt_rap *rap, struct bt_gatt_client *client);
void bt_rap_detach(struct bt_rap *rap);
struct bt_att *bt_rap_get_att(struct bt_rap *rap);
+struct bt_rap *bt_rap_get_session(struct bt_att *att, struct gatt_db *db);
bool bt_rap_set_user_data(struct bt_rap *rap, void *user_data);
--
^ permalink raw reply related
* [PATCH BlueZ v5 2/2] profiles: centralize reflector setup
From: Naga Bhavani Akella @ 2026-07-21 8:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260721084121.688467-1-naga.akella@oss.qualcomm.com>
Add a helper for reflector initialization and track D-Bus registration
state in rap_data. Simplify connection handling, move interface cleanup
to object destruction, and streamline removal logic.
Remove the legacy RAS accessed callback path and its registration
handling from initialization and shutdown.
---
profiles/ranging/rap.c | 137 +++++++++++++++++++++++++----------------
1 file changed, 84 insertions(+), 53 deletions(-)
diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
index 3ffc0da76..71cdc592b 100644
--- a/profiles/ranging/rap.c
+++ b/profiles/ranging/rap.c
@@ -65,10 +65,12 @@ struct rap_data {
void *hci_sm; /* Per-device HCI state machine */
uint16_t conn_handle; /* Last known connection handle */
struct cs_session active_session; /* active==false when idle */
+ bool dbus_registered;
};
static struct queue *sessions;
static struct queue *adapter_list; /* List of rap_adapter_data */
+static int rap_setup_reflector(struct rap_data *data);
/* Adapter data management */
static bool match_adapter(const void *data, const void *match_data)
@@ -218,6 +220,13 @@ static bool match_data(const void *data, const void *match_data)
static void rap_data_free(struct rap_data *data)
{
+ if (data->dbus_registered) {
+ g_dbus_unregister_interface(btd_get_dbus_connection(),
+ device_get_path(data->device),
+ CS_INTERFACE);
+ data->dbus_registered = false;
+ }
+
if (data->service) {
btd_service_set_user_data(data->service, NULL);
bt_rap_set_user_data(data->rap, NULL);
@@ -281,14 +290,13 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
struct rap_data *data;
struct bt_att *att;
struct btd_device *device;
+ int err;
DBG("%p", rap);
data = queue_find(sessions, match_data, rap);
- if (data) {
- DBG("data is already present");
- return;
- }
+ if (data)
+ goto setup;
att = bt_rap_get_att(rap);
if (!att) {
@@ -306,6 +314,11 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
data->rap = rap;
rap_data_add(data);
+
+setup:
+ err = rap_setup_reflector(data);
+ if (err)
+ error("Failed to set up reflector session: %d", err);
}
enum cs_dict_target {
@@ -662,19 +675,13 @@ static void rap_remove(struct btd_service *service)
return;
}
- g_dbus_unregister_interface(btd_get_dbus_connection(),
- device_get_path(device),
- CS_INTERFACE);
-
rap_data_remove(data);
}
-static int rap_accept(struct btd_service *service)
+static int rap_setup_reflector(struct rap_data *data)
{
- struct btd_device *device = btd_service_get_device(service);
+ struct btd_device *device = data->device;
struct btd_adapter *adapter = device_get_adapter(device);
- struct bt_gatt_client *client = btd_device_get_gatt_client(device);
- struct rap_data *data = btd_service_get_user_data(service);
struct bt_att *att;
const bdaddr_t *bdaddr;
uint8_t bdaddr_type;
@@ -682,26 +689,18 @@ static int rap_accept(struct btd_service *service)
char addr[18];
ba2str(device_get_address(device), addr);
- DBG("%s", addr);
- if (!data) {
- error("RAP Service not handled by profile");
- return -EINVAL;
- }
-
- /* init shared adapter HCI channel */
- if (!data->adapter_data) {
- data->adapter_data = rap_adapter_data_ref(adapter);
+ if (!data->hci_sm) {
if (!data->adapter_data) {
- error("Failed to get adapter HCI channel");
- return -EINVAL;
+ data->adapter_data = rap_adapter_data_ref(adapter);
+ if (!data->adapter_data) {
+ error("Failed to get adapter HCI channel");
+ return -EINVAL;
+ }
+ DBG("Using shared HCI channel for adapter (ref =%d)",
+ data->adapter_data->ref_count);
}
- DBG("Using shared HCI channel for adapter (ref_count=%d)",
- data->adapter_data->ref_count);
- }
- /* per-device HCI state machine */
- if (!data->hci_sm) {
data->hci_sm = bt_rap_attach_hci(data->rap,
data->adapter_data->hci,
btd_opts.defaults.bcs.role,
@@ -721,38 +720,70 @@ static int rap_accept(struct btd_service *service)
data);
}
- if (!bt_rap_attach(data->rap, client)) {
- error("RAP unable to attach");
- return -EINVAL;
- }
-
- /* Set up connection handle mapping for CS event routing */
- att = bt_rap_get_att(data->rap);
- bdaddr = device_get_address(device);
- bdaddr_type = device_get_le_address_type(device);
-
- if (att && data->adapter_data->hci && data->hci_sm) {
- if (bt_hci_get_conn_handle(data->adapter_data->hci,
- (const uint8_t *) bdaddr, &handle)) {
- DBG("Found conn handle 0x%04X for %s", handle, addr);
- data->conn_handle = handle;
- bt_rap_set_conn_hndl(data->hci_sm,
+ /* Set up connection handle mapping for CS event routing. Retried on
+ * every call until it succeeds, since att may not be available yet
+ * the first time this runs (e.g. called from bt_rap_attach()'s
+ * attached callback before rap->client/att are set).
+ */
+ if (!data->conn_handle) {
+ att = bt_rap_get_att(data->rap);
+ bdaddr = device_get_address(device);
+ bdaddr_type = device_get_le_address_type(device);
+
+ if (att && data->adapter_data->hci) {
+ if (bt_hci_get_conn_handle(data->adapter_data->hci,
+ (const uint8_t *)bdaddr, &handle)) {
+ DBG("conn handle 0x%04X for %s", handle, addr);
+ data->conn_handle = handle;
+ bt_rap_set_conn_hndl(data->hci_sm,
data->rap, handle,
- (const uint8_t *) bdaddr,
+ (const uint8_t *)bdaddr,
bdaddr_type,
btd_device_is_initiator(device));
- } else {
- error("Failed to find connection handle for device %s",
- addr);
+ } else {
+ error("Failed to find conn for device %s",
+ addr);
+ }
}
}
- btd_service_connecting_complete(service, 0);
+ if (!data->dbus_registered) {
+ g_dbus_register_interface(btd_get_dbus_connection(),
+ device_get_path(device),
+ CS_INTERFACE, cs_dbus_methods,
+ NULL, cs_dbus_properties, data, NULL);
+ data->dbus_registered = true;
+ }
+
+ return 0;
+}
+
+static int rap_accept(struct btd_service *service)
+{
+ struct btd_device *device = btd_service_get_device(service);
+ struct bt_gatt_client *client = btd_device_get_gatt_client(device);
+ struct rap_data *data = btd_service_get_user_data(service);
+ char addr[18];
+ int err;
- g_dbus_register_interface(btd_get_dbus_connection(),
- device_get_path(data->device),
- CS_INTERFACE, cs_dbus_methods,
- NULL, cs_dbus_properties, data, NULL);
+ ba2str(device_get_address(device), addr);
+ DBG("%s", addr);
+
+ if (!data) {
+ error("RAP Service not handled by profile");
+ return -EINVAL;
+ }
+
+ if (!bt_rap_attach(data->rap, client)) {
+ error("RAP unable to attach");
+ return -EINVAL;
+ }
+
+ err = rap_setup_reflector(data);
+ if (err)
+ return err;
+
+ btd_service_connecting_complete(service, 0);
return 0;
}
--
^ permalink raw reply related
* Re: [PATCH RFC] Bluetooth: Add generic support for vendor HCI frames
From: Zijun Hu @ 2026-07-21 8:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Zijun Hu, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZL_H2iRAshF-RCX41jbt0jots5i5W=aUUJC_wEN6wzp=w@mail.gmail.com>
On 7/20/2026 10:30 PM, Luiz Augusto von Dentz wrote:
>> For Qualcomm multi-subsystem BT chips, the transport wire carries both
>> BT-HCI and PERI-HCI frames. PERI is a subsystem on the chip. Take the
>> upcoming QCC2072 support as an example:
>>
>> Packet type BT-HCI indicator PERI-HCI indicator
>> --------------------------------------------------------------
>> CMD (Host -> Controller) 0x01 0x31
>> ACL Data (bidirectional) 0x02 0x32
>> EVENT (Controller -> Host) 0x04 0x34
> I would say this was fine, but you actuall need to reclassify these to
> 0xff and then use an extra byte for the vendor opcode. Btw, you said
> you could define H4 headers like this? The spec defines either:
>
> https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core_v6.3/out/en/host-controller-interface/three-wire-uart-transport-layer.html#UUID-1cf959bb-57a0-e782-4324-a9bc4ee3f134_table-idm13359018144714
>
> Or
>
> https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core_v6.3/out/en/host-controller-interface/uart-transport-layer.html#UUID-83881875-5fbb-c366-400f-055ba726f70e_table-idm13359015052542
>
Hi Luiz,
Let us label this approach — which multiplexes the vendor indicator under 0xff — Solution A:
virtual HCI_VENDOR_PKT (0xff) + vendor indicator (0x31/0x32/0x34) + body per indicator
I did consider this solution — let us discuss it in the section below.
The PERI-HCI indicators (0x31/0x32/0x34) are defined by the Qualcomm Bluetooth Extensions
specification for the USB (Bulk Serialization mode), H4 UART, and SPI transports. They have
already been deployed in several generations of commercial multi-subsystem BT chips.
> We end up defining vendor 0xff because it is at the end of the range
> which is probably safer.
>
I am not sure that fully holds here:
First, vendors likely reason the same way — "end of range is safer", Take Qualcomm as an example:
it already used 0xfb/0xfc/0xfd/0xfe as internal indicators.
Second, current transport drivers already use 0xff in ways that break that expectation,
as shown below:
1) bpa10x uses 0xff as the wire indicator for HCI_DIAG_PKT (0xf0):
https://elixir.bootlin.com/linux/v7.1/source/drivers/bluetooth/bpa10x.c#L72
2) btmrvl remaps its wire vendor type 0xFE onto 0xff to carry Marvell vendor events:
https://elixir.bootlin.com/linux/v7.1/source/drivers/bluetooth/btmrvl_sdio.c#L797
3) hci_vhci uses it for the handshake that creates the virtual hdev:
https://elixir.bootlin.com/linux/v7.1/source/drivers/bluetooth/hci_vhci.c#L462
https://elixir.bootlin.com/linux/v7.1/source/drivers/bluetooth/hci_vhci.c#L523
>> To generically support vendor HCI frames:
>>
>> - Show them in btmon logs as they appear on the wire.
>> - Allow userspace to send/receive them via HCI_CHANNEL_USER, with a
>> socket option to control RX, defaulting off to eliminate regression
>> risk for existing applications.
> We shouldn't need to do this, we should just accept 0xff as the vendor
> packet type and then use the following byte as the real opcode (0x31,
> 0x32, 0x34). Otherwise, if we start accepting vendor packet types
> outside 0xff this will get crowded quickly and could potentially clash
> with future specs.
>
The indicator is a full u8, the entire [0x10, 0xef] indicator range is currently
unused, and vendor indicators should be deliberately chosen to avoid conflicting with
the BT SIG assignments.
>> - Add hdev->recv_vendor() to handle vendor frames in hci_rx_work() like
>> BT frame handlers.
>> - Add hci_send_vendor_frame() API similar to existing __hci_cmd_send().
> Encoding/decoding of the frames should be transparent. I'm fine adding
> code to the likes of btmon to decode vendor packets, we already have
> something similar for Intel although that uses a vendor event not a
> vendor packet (both use 0xff, causing the confusion). The user of the
> user channel shall be able to read/write starting with 0xff then
> decode/encode the next byte as the actual vendor opcode.
>
>> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
>> ---
>> Hi Luiz
>> To address the below concerns you raised on previous
>> discussion, and inspired from your suggestion to add hdev callback:
>>
>> - Not use safer skb helper like skb_pull_data()
>> - It will skip sending to the monitor, making debugging much harder
>>
>> Looking forward to your further comments.
>>
>> Why hdev->is_vendor() instead of multiplexing vendor frames under a
>> virtual HCI_VENDOR_PKT + vendor indicator byte ?
>>
>> 1) The virtual HCI_VENDOR_PKT isn't used by the core itself
>> currently, and may be removed later.
>> 2) It makes full use of the indicator (hci_skb_pkt_type(skb)) space,
>> which is large enough to accommodate vendor frames without an
>> extra layer of nesting inside HCI_VENDOR_PKT.
>> 3) It lets userspace and btmon logs see the exact same frame as it
>> appears on the wire.
As noted above, I chose is_vendor() over Solution A. My reasoning follows,
for your reference.
1) Userspace sees exactly what is on the wire, in the same form as BT-HCI frames —
clear and consistent, as shown below:
┌───────┬──────────┬────────────┬────────────┐
│ Frame │ BT-HCI │ PERI-HCI │ PERI-HCI │
│ │ existing │ is_vendor()│ Solution A │
├───────┼──────────┼────────────┼────────────┤
│ CMD │ 0x01 … │ 0x31 … │ 0xff 0x31… │
├───────┼──────────┼────────────┼────────────┤
│ ACL │ 0x02 … │ 0x32 … │ 0xff 0x32… │
├───────┼──────────┼────────────┼────────────┤
│ EVENT │ 0x04 … │ 0x34 … │ 0xff 0x34… │
└───────┴──────────┴────────────┴────────────┘
2) is_vendor() puts PERI-HCI on an equal footing with BT-HCI, so userspace and the transport
driver can reuse the existing BT-HCI path rather than add a separate encode/decode layer —
less effort on both sides.
Could you please give me a clear direction
Solution A or is_vendor()?
I need it before I can move forward with the remaining QCC2072 btusb development work.
thank you.
^ permalink raw reply
* Re: [PATCH bluez RFC 2/3] doc: hci-protocol: Add sock option BT_RCV_VENDOR_PKT for HCI_CHANNEL_USER
From: Zijun Hu @ 2026-07-21 9:07 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Zijun Hu, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZK0RSZ6xOgkx=wcme9kUWXFHydAvHR+EXwkp4eJwp-QKw@mail.gmail.com>
On 7/20/2026 10:10 PM, Luiz Augusto von Dentz wrote:
>> +-----------------------------------
>> +
>> +Enable receiving vendor HCI frames, requires hci_channel to be set to
>> +HCI_CHANNEL_USER.
>> +
>> +Default is disabled.
>> +
>> +Example:
>> +
>> +.. code-block::
>> +
>> + int enable = 1;
>> + int err;
>> +
>> + err = setsockopt(fd, SOL_BLUETOOTH, BT_RCV_VENDOR_PKT, &enable,
>> + sizeof(enable));
>> +
> I don't think we have any socket option with this name, besides this
> should really go as an HCI packet with an H4 header set accordingly.
Hi Luiz,
I named it after BT_SNDMTU/BT_RCVMTU, but that may not be a good fit.
Any preferred name?
Happy to rename.
^ permalink raw reply
* [bluez/bluez] ede1b1: rap: use session lookup for RAS operations
From: Bhavani @ 2026-07-21 9:16 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1131452
Home: https://github.com/bluez/bluez
Commit: ede1b10d67642eba459a9b9b8860d844ded0997c
https://github.com/bluez/bluez/commit/ede1b10d67642eba459a9b9b8860d844ded0997c
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-21 (Tue, 21 Jul 2026)
Changed paths:
M src/shared/rap.c
M src/shared/rap.h
Log Message:
-----------
rap: use session lookup for RAS operations
Store disconnect information in RAP state and
centralize attachment handling through dedicated helpers.
Add bt_rap_get_session() and use it from all RAS
GATT server callbacks instead of the previous accessed
notification bridge. As part of the cleanup,
remove the accessed callback registration APIs,
related notification code, and the unused timeout.h include
Commit: a12498ad4b814638833fd7a2f2b35e24ad4799b0
https://github.com/bluez/bluez/commit/a12498ad4b814638833fd7a2f2b35e24ad4799b0
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-21 (Tue, 21 Jul 2026)
Changed paths:
M profiles/ranging/rap.c
Log Message:
-----------
profiles: centralize reflector setup
Add a helper for reflector initialization and track D-Bus registration
state in rap_data. Simplify connection handling, move interface cleanup
to object destruction, and streamline removal logic.
Remove the legacy RAS accessed callback path and its registration
handling from initialization and shutdown.
Compare: https://github.com/bluez/bluez/compare/ede1b10d6764%5E...a12498ad4b81
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH v3] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: Pauli Virtanen @ 2026-07-21 9:19 UTC (permalink / raw)
To: linux-bluetooth
Cc: Pauli Virtanen, marcel, luiz.dentz, iulia.tanasescu, linux-kernel
iso_sock_disconn() aims to disconnect the hcon by dropping it, which
triggers iso_conn_del() to tear down the iso_conn once the HCI operation
completes, which requires valid hcon->iso_data. iso_sock_disconn() sets
conn->hcon = NULL to avoid a second drop, but also preventing clearing
hcon->iso_data on socket release. Closing the socket before
iso_conn_del() runs then results to UAF.
Fix by using a separate flag to track the hcon drop status, instead of
clearing conn->hcon.
Log: (BlueZ iso-tester ISO Connect Close - Success)
BUG: KASAN: slab-use-after-free in iso_conn_hold_unless_zero
...
iso_conn_hold_unless_zero (net/bluetooth/iso.c:138)
iso_conn_del (net/bluetooth/iso.c:270)
hci_conn_failed (net/bluetooth/hci_conn.c:1408)
hci_abort_conn_sync (net/bluetooth/hci_sync.c:5817)
Allocated by task 34:
iso_conn_add (net/bluetooth/iso.c:216)
iso_connect_cis (net/bluetooth/iso.c:507)
iso_sock_connect (net/bluetooth/iso.c:1211)
__sys_connect (net/socket.c:2148)
Freed by task 34:
iso_chan_del (net/bluetooth/iso.c:248)
iso_sock_close (net/bluetooth/iso.c:885)
iso_sock_release (net/bluetooth/iso.c:2022)
sock_close (net/socket.c:722)
Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
---
Notes:
v3:
- use test_and_set_bit() instead of lock + bool
v2:
- use flag to track dropping instead of detaching sk
in iso_sock_disconn()
On previous Sashiko comment (IIUC this note text is included in the
context, maybe generates better review): iso_connect_cfm() with status
!= 0 or iso_disconn_cfm() is guaranteed to be called before the ISO
hci_conn is deleted. It should then go to iso_conn_del() which is
supposed to limit the lifetime of the associated iso_conn to be shorter
than hci_conn.
hci_conn::iso_data is not associated with iso_conn refcount, but
iso_pi(sk)->conn is supposed to hold one when non-NULL.
net/bluetooth/iso.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index 2e95a153912c..5dc2915f7b32 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -24,8 +24,14 @@ static struct bt_sock_list iso_sk_list = {
};
/* ---- ISO connections ---- */
+enum {
+ ISO_CONN_DROPPED,
+ __ISO_CONN_NUM_FLAGS
+};
+
struct iso_conn {
struct hci_conn *hcon;
+ DECLARE_BITMAP(flags, __ISO_CONN_NUM_FLAGS);
/* @lock: spinlock protecting changes to iso_conn fields */
spinlock_t lock;
@@ -107,7 +113,8 @@ static void iso_conn_free(struct kref *ref)
if (conn->hcon) {
conn->hcon->iso_data = NULL;
- hci_conn_drop(conn->hcon);
+ if (!test_and_set_bit(ISO_CONN_DROPPED, conn->flags))
+ hci_conn_drop(conn->hcon);
}
/* Ensure no more work items will run since hci_conn has been dropped */
@@ -306,6 +313,7 @@ static int __iso_chan_add(struct iso_conn *conn, struct sock *sk,
iso_pi(sk)->conn = conn;
conn->sk = sk;
+ clear_bit(ISO_CONN_DROPPED, conn->flags);
if (parent)
bt_accept_enqueue(parent, sk, true);
@@ -835,10 +843,8 @@ static void iso_sock_disconn(struct sock *sk)
}
sk->sk_state = BT_DISCONN;
- iso_conn_lock(iso_pi(sk)->conn);
- hci_conn_drop(iso_pi(sk)->conn->hcon);
- iso_pi(sk)->conn->hcon = NULL;
- iso_conn_unlock(iso_pi(sk)->conn);
+ if (!test_and_set_bit(ISO_CONN_DROPPED, iso_pi(sk)->conn->flags))
+ hci_conn_drop(iso_pi(sk)->conn->hcon);
}
static void __iso_sock_close(struct sock *sk)
--
2.55.0
^ permalink raw reply related
* [PATCH BlueZ] tools/iso-tester: add tests for socket shutdown with linger enabled
From: Pauli Virtanen @ 2026-07-21 9:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pauli Virtanen
Add tests with SO_LINGER enabled, to test kernel sock transitions
properly to BT_CLOSED on shutdown.
Unlike L2CAP, ISO sockets don't have a feature to send POLLHUP only
after HCI Disconnect is received, so only SO_LINGER can be used to test
the sequence is shutdown -> Disconnect, HUP -> release, and not
shutdown -> HUP -> release -> Disconnect.
Add tests:
ISO Defer Linger - Success
ISO Connect Linger - Success
---
tools/iso-tester.c | 68 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 67 insertions(+), 1 deletion(-)
diff --git a/tools/iso-tester.c b/tools/iso-tester.c
index fe27eaaf3..a792a804b 100644
--- a/tools/iso-tester.c
+++ b/tools/iso-tester.c
@@ -478,6 +478,7 @@ struct test_data {
bool suspending;
struct tx_tstamp_data tx_ts;
int seqnum;
+ GThread *thread;
};
struct iso_client_data {
@@ -522,6 +523,9 @@ struct iso_client_data {
* Used for testing TX timestamping OPT_ID.
*/
unsigned int repeat_send;
+
+ /* Whether to enable SO_LINGER (for test_connect_wait_close) */
+ bool so_linger;
};
typedef bool (*iso_defer_accept_t)(struct test_data *data, GIOChannel *io,
@@ -717,6 +721,11 @@ static void test_post_teardown(const void *test_data)
hciemu_unref(data->hciemu);
data->hciemu = NULL;
+
+ if (data->thread) {
+ g_thread_unref(data->thread);
+ data->thread = NULL;
+ }
}
static void test_data_free(void *test_data)
@@ -1352,6 +1361,19 @@ static const struct iso_client_data connect_ac_1_2_cig_1_2 = {
.mconn = true,
};
+static const struct iso_client_data linger_16_2_1 = {
+ .qos = QOS_16_2_1,
+ .expect_err = 0,
+ .so_linger = true,
+};
+
+static const struct iso_client_data linger_defer_16_2_1 = {
+ .qos = QOS_16_2_1,
+ .expect_err = 0,
+ .defer = true,
+ .so_linger = true,
+};
+
static const struct iso_client_data bcast_48_1_g = {
.qos = QOS_OUT_48_1_g,
.expect_err = 0,
@@ -3679,6 +3701,19 @@ static void test_connect2_busy(const void *test_data)
setup_connect(data, 0, iso_connect_cb_busy);
}
+static gpointer shutdown_sk_thread_cb(gpointer data)
+{
+ int sk = PTR_TO_UINT(data);
+ struct timespec start, end;
+
+ clock_gettime(CLOCK_MONOTONIC, &start);
+ shutdown(sk, SHUT_RDWR);
+ clock_gettime(CLOCK_MONOTONIC, &end);
+
+ /* Completed before linger timeout? */
+ return UINT_TO_PTR(TS_NSEC(&end) - TS_NSEC(&start) < SEC_NSEC(2));
+}
+
static gboolean iso_connect_close_cb(GIOChannel *io, GIOCondition cond,
gpointer user_data)
{
@@ -3688,6 +3723,13 @@ static gboolean iso_connect_close_cb(GIOChannel *io, GIOCondition cond,
tester_print("Disconnected");
+ if (data->thread) {
+ /* Wait for shutdown() to complete, for linger enabled */
+ if (!g_thread_join(data->thread))
+ tester_test_failed();
+ data->thread = NULL;
+ }
+
--data->step;
if (!data->step)
tester_test_passed();
@@ -3737,16 +3779,34 @@ static gboolean iso_connect_wait_close_cb(GIOChannel *io, GIOCondition cond,
gpointer user_data)
{
struct test_data *data = tester_get_data();
+ const struct iso_client_data *isodata = data->test_data;
int sk;
tester_print("Connected");
sk = g_io_channel_unix_get_fd(io);
+ if (isodata->so_linger) {
+ struct linger val = { .l_onoff = 1, .l_linger = 2 };
+
+ if (setsockopt(sk, SOL_SOCKET, SO_LINGER, &val, sizeof(val))) {
+ tester_warn("Can't set socket option : %s (%d)",
+ strerror(errno), errno);
+ tester_test_failed();
+ return FALSE;
+ }
+ }
+
data->io_id[0] = g_io_add_watch(io, G_IO_HUP, iso_connect_close_cb,
data);
- shutdown(sk, SHUT_RDWR);
+ if (!isodata->so_linger)
+ shutdown(sk, SHUT_RDWR);
+ else {
+ /* With linger shutdown() blocks, so run in separate thread */
+ data->thread = g_thread_new("close_sk", shutdown_sk_thread_cb,
+ UINT_TO_PTR(sk));
+ }
return FALSE;
}
@@ -4160,6 +4220,12 @@ int main(int argc, char *argv[])
test_iso("ISO Connect Wait Close - Success", &connect_16_2_1,
setup_powered, test_connect_wait_close);
+ test_iso("ISO Defer Linger - Success", &linger_16_2_1,
+ setup_powered, test_connect_wait_close);
+
+ test_iso("ISO Connect Linger - Success", &linger_defer_16_2_1,
+ setup_powered, test_connect_wait_close);
+
test_iso("ISO Connect Suspend - Success", &connect_suspend,
setup_powered,
test_connect_suspend);
--
2.55.0
^ permalink raw reply related
* RE: Bluetooth: sco: Remove redundant mtu assignment in sco_conn_add()
From: bluez.test.bot @ 2026-07-21 9:32 UTC (permalink / raw)
To: linux-bluetooth, winter91
In-Reply-To: <tencent_C817DCB733CA5C38DBF7EE648B196E904509@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1235 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=1131416
---Test result---
Test Summary:
CheckPatch PASS 0.77 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 26.84 seconds
CheckAllWarning PASS 29.58 seconds
CheckSparse PASS 27.91 seconds
BuildKernel32 PASS 26.18 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 489.37 seconds
TestRunner_sco-tester PASS 31.31 seconds
IncrementalBuild PASS 25.58 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/468
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: RAP: streamline session handling, reflector setup
From: bluez.test.bot @ 2026-07-21 9:48 UTC (permalink / raw)
To: linux-bluetooth, naga.akella
In-Reply-To: <20260721084121.688467-2-naga.akella@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 987 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=1131452
---Test result---
Test Summary:
CheckPatch PASS 0.89 seconds
GitLint PASS 0.50 seconds
BuildEll PASS 14.91 seconds
BluezMake PASS 369.85 seconds
MakeCheck PASS 0.83 seconds
MakeDistcheck PASS 118.70 seconds
CheckValgrind PASS 112.98 seconds
CheckSmatch PASS 203.48 seconds
bluezmakeextell PASS 73.27 seconds
IncrementalBuild PASS 371.90 seconds
ScanBuild PASS 626.25 seconds
https://github.com/bluez/bluez/pull/2336
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v2 0/3] Bluetooth: Replace HCI_VENDOR_PKT usages with HCI_EV_VENDOR
From: Zijun Hu @ 2026-07-21 10:14 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-arm-msm, linux-bluetooth, linux-kernel, Zijun Hu,
Bartosz Golaszewski
The macros below have different meanings even though they share the
same value 0xff:
HCI_VENDOR_PKT: HCI packet indicator or type
HCI_EV_VENDOR: event code of a VSE
several usage of HCI_VENDOR_PKT is wrongly checking an event code.
Fix by using HCI_EV_VENDOR for event code.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
---
Changes in v2:
- Rebase and fix conflict for the last commit
- Link to v1: https://lore.kernel.org/r/20260717-fix_vendor-v1-0-f22263c1175b@oss.qualcomm.com
To: Bartosz Golaszewski <brgl@kernel.org>
To: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Zijun Hu <zijun_hu@icloud.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Zijun Hu (3):
Bluetooth: hci_qca: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDOR
Bluetooth: btusb: QCA: Replace HCI_VENDOR_PKT usages with HCI_EV_VENDOR
Bluetooth: btusb: Realtek: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDOR
drivers/bluetooth/btusb.c | 6 +++---
drivers/bluetooth/hci_qca.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
---
base-commit: 891916abe16fc409d6e600ddd41b86ecd8f5a9df
change-id: 20260717-fix_vendor-6f40af4b1c91
Best regards,
--
Zijun Hu <zijun.hu@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/3] Bluetooth: hci_qca: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDOR
From: Zijun Hu @ 2026-07-21 10:14 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-arm-msm, linux-bluetooth, linux-kernel, Zijun Hu,
Bartosz Golaszewski
In-Reply-To: <20260721-fix_vendor-v2-0-1977a8c39708@oss.qualcomm.com>
The macros below have different meanings even though they share the
same value 0xff:
HCI_VENDOR_PKT: HCI packet indicator or type
HCI_EV_VENDOR: event code of a VSE
This usage of HCI_VENDOR_PKT is wrongly checking an event code.
Fix by using HCI_EV_VENDOR for event code.
Also fix warning "CHECK: Unnecessary parentheses around comparison"
given by checkpatch.pl.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
---
drivers/bluetooth/hci_qca.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index bd29d422c209..f978087612ee 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1240,8 +1240,8 @@ static int qca_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
* received we store dump into a file before closing hci. This
* dump will help in triaging the issues.
*/
- if ((skb->data[0] == HCI_VENDOR_PKT) &&
- (get_unaligned_be16(skb->data + 2) == QCA_SSR_DUMP_HANDLE))
+ if (skb->data[0] == HCI_EV_VENDOR &&
+ get_unaligned_be16(skb->data + 2) == QCA_SSR_DUMP_HANDLE)
return qca_controller_memdump_event(hdev, skb);
return hci_recv_frame(hdev, skb);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] Bluetooth: btusb: QCA: Replace HCI_VENDOR_PKT usages with HCI_EV_VENDOR
From: Zijun Hu @ 2026-07-21 10:14 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-arm-msm, linux-bluetooth, linux-kernel, Zijun Hu
In-Reply-To: <20260721-fix_vendor-v2-0-1977a8c39708@oss.qualcomm.com>
The macros below have different meanings even though they share the
same value 0xff:
HCI_VENDOR_PKT: HCI packet indicator or type
HCI_EV_VENDOR: event code of a VSE
These usages of HCI_VENDOR_PKT are wrongly checking an event code.
Fix by using HCI_EV_VENDOR for event code.
Also fix warning "CHECK: Unnecessary parentheses around comparison"
given by checkpatch.pl.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
---
drivers/bluetooth/btusb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index f7cce0cf472e..3847a0f6d096 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3278,7 +3278,7 @@ static bool acl_pkt_is_dump_qca(struct hci_dev *hdev, struct sk_buff *skb)
goto out;
event_hdr = skb_pull_data(clone, sizeof(*event_hdr));
- if (!event_hdr || (event_hdr->evt != HCI_VENDOR_PKT))
+ if (!event_hdr || event_hdr->evt != HCI_EV_VENDOR)
goto out;
dump_hdr = skb_pull_data(clone, sizeof(*dump_hdr));
@@ -3304,7 +3304,7 @@ static bool evt_pkt_is_dump_qca(struct hci_dev *hdev, struct sk_buff *skb)
return false;
event_hdr = skb_pull_data(clone, sizeof(*event_hdr));
- if (!event_hdr || (event_hdr->evt != HCI_VENDOR_PKT))
+ if (!event_hdr || event_hdr->evt != HCI_EV_VENDOR)
goto out;
dump_hdr = skb_pull_data(clone, sizeof(*dump_hdr));
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] Bluetooth: btusb: Realtek: Replace HCI_VENDOR_PKT usage with HCI_EV_VENDOR
From: Zijun Hu @ 2026-07-21 10:14 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-arm-msm, linux-bluetooth, linux-kernel, Zijun Hu
In-Reply-To: <20260721-fix_vendor-v2-0-1977a8c39708@oss.qualcomm.com>
The macros below have different meanings even though they share the
same value 0xff:
HCI_VENDOR_PKT: HCI packet indicator or type
HCI_EV_VENDOR: event code of a VSE
This usage of HCI_VENDOR_PKT is wrongly checking an event code.
Fix by using HCI_EV_VENDOR for event code.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3847a0f6d096..4d59b28ab30f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2800,7 +2800,7 @@ static int btusb_setup_realtek(struct hci_dev *hdev)
static int btusb_recv_event_realtek(struct hci_dev *hdev, struct sk_buff *skb)
{
if (skb->len >= HCI_EVENT_HDR_SIZE + 1 &&
- skb->data[0] == HCI_VENDOR_PKT &&
+ skb->data[0] == HCI_EV_VENDOR &&
skb->data[2] == RTK_SUB_EVENT_CODE_COREDUMP) {
struct rtk_dev_coredump_hdr hdr = {
.code = RTK_DEVCOREDUMP_CODE_MEMDUMP,
--
2.34.1
^ permalink raw reply related
* RE: [BlueZ] tools/iso-tester: add tests for socket shutdown with linger enabled
From: bluez.test.bot @ 2026-07-21 11:18 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <f81384d367ad95cbe74338eba688daa46b379feb.1784624911.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 538 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: tools/iso-tester.c:717
error: tools/iso-tester.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
* RE: Bluetooth: Replace HCI_VENDOR_PKT usages with HCI_EV_VENDOR
From: bluez.test.bot @ 2026-07-21 11:19 UTC (permalink / raw)
To: linux-bluetooth, zijun.hu
In-Reply-To: <20260721-fix_vendor-v2-1-1977a8c39708@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 553 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: drivers/bluetooth/btusb.c:2800
error: drivers/bluetooth/btusb.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
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