* [PATCH RFC] Bluetooth: Add generic support for vendor HCI frames
From: Zijun Hu @ 2026-07-20 5:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Zijun Hu
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
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.
- 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().
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.
Previous discussion link:
https://lore.kernel.org/all/CABBYNZJpdeoZ16bObLRPhng2dfyNeK9ix9_-z_hMZhJ0QxTxGg@mail.gmail.com
https://lore.kernel.org/all/CABBYNZJ0zoVVVxuM48L=Km==gnrQuskrbjB6q_aNV0KEEY3+5w@mail.gmail.com
---
include/net/bluetooth/bluetooth.h | 2 +
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 13 +++++++
include/net/bluetooth/hci_mon.h | 2 +
net/bluetooth/hci_core.c | 22 +++++++++++
net/bluetooth/hci_sock.c | 78 ++++++++++++++++++++++++++++++++++-----
6 files changed, 108 insertions(+), 10 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index b624da5026f5..d9870a43a2c4 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -256,6 +256,8 @@ struct bt_codecs {
#define BT_SCM_PKT_SEQNUM 0x05
+#define BT_RCV_VENDOR_PKT 23
+
__printf(1, 2)
void bt_info(const char *fmt, ...);
__printf(1, 2)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 50f0eef71fb1..ac97550cbdba 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -398,6 +398,7 @@ enum {
/* HCI socket flags */
enum {
HCI_SOCK_TRUSTED,
+ HCI_SOCK_RCV_VENDOR_PKT,
HCI_MGMT_INDEX_EVENTS,
HCI_MGMT_UNCONF_INDEX_EVENTS,
HCI_MGMT_EXT_INDEX_EVENTS,
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e7133ff87fbf..20a455d90ef3 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -645,6 +645,8 @@ struct hci_dev {
int (*setup)(struct hci_dev *hdev);
int (*shutdown)(struct hci_dev *hdev);
int (*send)(struct hci_dev *hdev, struct sk_buff *skb);
+ bool (*is_vendor)(struct hci_dev *hdev, const struct sk_buff *skb);
+ void (*recv_vendor)(struct hci_dev *hdev, struct sk_buff *skb);
void (*notify)(struct hci_dev *hdev, unsigned int evt);
void (*hw_error)(struct hci_dev *hdev, u8 code);
int (*post_init)(struct hci_dev *hdev);
@@ -660,6 +662,15 @@ struct hci_dev {
u8 (*classify_pkt_type)(struct hci_dev *hdev, struct sk_buff *skb);
};
+static inline bool hci_is_vendor_frame(struct hci_dev *hdev,
+ const struct sk_buff *skb)
+{
+ if (!hdev->is_vendor)
+ return false;
+
+ return hdev->is_vendor(hdev, skb);
+}
+
#define hci_set_quirk(hdev, nr) set_bit((nr), (hdev)->quirk_flags)
#define hci_clear_quirk(hdev, nr) clear_bit((nr), (hdev)->quirk_flags)
#define hci_test_quirk(hdev, nr) test_bit((nr), (hdev)->quirk_flags)
@@ -2327,6 +2338,8 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
int hci_register_cb(struct hci_cb *hcb);
int hci_unregister_cb(struct hci_cb *hcb);
+int hci_send_vendor_frame(struct hci_dev *hdev, struct sk_buff *skb);
+
int __hci_cmd_send(struct hci_dev *hdev, u16 opcode, u32 plen,
const void *param);
diff --git a/include/net/bluetooth/hci_mon.h b/include/net/bluetooth/hci_mon.h
index 4b2a0af4ed58..7710688c0d30 100644
--- a/include/net/bluetooth/hci_mon.h
+++ b/include/net/bluetooth/hci_mon.h
@@ -50,6 +50,8 @@ struct hci_mon_hdr {
#define HCI_MON_ISO_RX_PKT 19
#define HCI_MON_DRV_TX_PKT 20
#define HCI_MON_DRV_RX_PKT 21
+#define HCI_MON_VENDOR_TX_PKT 22
+#define HCI_MON_VENDOR_RX_PKT 23
struct hci_mon_new_index {
__u8 type;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 1e324c05af24..c12c180e8293 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2920,6 +2920,8 @@ int hci_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
case HCI_DRV_PKT:
break;
default:
+ if (hci_is_vendor_frame(hdev, skb))
+ break;
kfree_skb(skb);
return -EINVAL;
}
@@ -3053,6 +3055,18 @@ static int hci_send_conn_frame(struct hci_dev *hdev, struct hci_conn *conn,
return hci_send_frame(hdev, skb);
}
+int hci_send_vendor_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ if (hci_is_vendor_frame(hdev, skb))
+ return hci_send_frame(hdev, skb);
+
+ bt_dev_err(hdev, "invalid vendor frame with pkt_type 0x%2.2x",
+ hci_skb_pkt_type(skb));
+ kfree_skb(skb);
+ return -EINVAL;
+}
+EXPORT_SYMBOL(hci_send_vendor_frame);
+
/* Send HCI command */
int hci_send_cmd(struct hci_dev *hdev, __u16 opcode, __u32 plen,
const void *param)
@@ -4066,6 +4080,14 @@ static void hci_rx_work(struct work_struct *work)
break;
default:
+ if (hci_is_vendor_frame(hdev, skb)) {
+ BT_DBG("%s Vendor packet with type 0x%2.2x",
+ hdev->name, hci_skb_pkt_type(skb));
+ if (hdev->recv_vendor) {
+ hdev->recv_vendor(hdev, skb);
+ break;
+ }
+ }
kfree_skb(skb);
break;
}
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 070ca388f9ac..903498e6db3d 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -229,12 +229,16 @@ void hci_send_to_sock(struct hci_dev *hdev, struct sk_buff *skb)
} else if (hci_pi(sk)->channel == HCI_CHANNEL_USER) {
if (!bt_cb(skb)->incoming)
continue;
- if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT &&
- hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
- hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
- hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
- hci_skb_pkt_type(skb) != HCI_DRV_PKT)
+ if (hci_is_vendor_frame(hdev, skb)) {
+ if (!hci_sock_test_flag(sk, HCI_SOCK_RCV_VENDOR_PKT))
+ continue;
+ } else if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT &&
+ hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
+ hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
+ hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
+ hci_skb_pkt_type(skb) != HCI_DRV_PKT) {
continue;
+ }
} else {
/* Don't send frame to other channel types */
continue;
@@ -359,6 +363,7 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
struct sk_buff *skb_copy = NULL;
struct hci_mon_hdr *hdr;
__le16 opcode;
+ bool is_vendor_frame = false;
if (!atomic_read(&monitor_promisc))
return;
@@ -400,7 +405,26 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
opcode = cpu_to_le16(HCI_MON_VENDOR_DIAG);
break;
default:
- return;
+ is_vendor_frame = hci_is_vendor_frame(hdev, skb);
+ if (!is_vendor_frame)
+ return;
+ if (bt_cb(skb)->incoming)
+ opcode = cpu_to_le16(HCI_MON_VENDOR_RX_PKT);
+ else
+ opcode = cpu_to_le16(HCI_MON_VENDOR_TX_PKT);
+ break;
+ }
+
+ if (is_vendor_frame) {
+ skb_copy = __pskb_copy_fclone(skb, HCI_MON_HDR_SIZE + 1,
+ GFP_ATOMIC, true);
+ if (!skb_copy)
+ return;
+
+ *(u8 *)skb_push(skb_copy, 1) = hci_skb_pkt_type(skb);
+ hdr = skb_push(skb_copy, HCI_MON_HDR_SIZE);
+ hdr->len = cpu_to_le16(skb->len + 1);
+ goto out_comm;
}
/* Create a private copy with headroom */
@@ -408,14 +432,15 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
if (!skb_copy)
return;
- hci_sock_copy_creds(skb->sk, skb_copy);
-
/* Put header before the data */
hdr = skb_push(skb_copy, HCI_MON_HDR_SIZE);
+ hdr->len = cpu_to_le16(skb->len);
+
+out_comm:
hdr->opcode = opcode;
hdr->index = cpu_to_le16(hdev->id);
- hdr->len = cpu_to_le16(skb->len);
+ hci_sock_copy_creds(skb->sk, skb_copy);
hci_send_to_channel(HCI_CHANNEL_MONITOR, skb_copy,
HCI_SOCK_TRUSTED, NULL);
kfree_skb(skb_copy);
@@ -1868,7 +1893,8 @@ static int hci_sock_sendmsg(struct socket *sock, struct msghdr *msg,
hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
- hci_skb_pkt_type(skb) != HCI_DRV_PKT) {
+ hci_skb_pkt_type(skb) != HCI_DRV_PKT &&
+ !hci_is_vendor_frame(hdev, skb)) {
err = -EINVAL;
goto drop;
}
@@ -2017,6 +2043,7 @@ static int hci_sock_setsockopt(struct socket *sock, int level, int optname,
{
struct sock *sk = sock->sk;
int err = 0;
+ int opt_int;
u16 opt;
BT_DBG("sk %p, opt %d", sk, optname);
@@ -2050,6 +2077,23 @@ static int hci_sock_setsockopt(struct socket *sock, int level, int optname,
hci_pi(sk)->mtu = opt;
break;
+ case BT_RCV_VENDOR_PKT:
+ if (hci_pi(sk)->channel != HCI_CHANNEL_USER) {
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ err = copy_safe_from_sockptr(&opt_int, sizeof(opt_int),
+ optval, optlen);
+ if (err)
+ break;
+
+ if (opt_int)
+ hci_sock_set_flag(sk, HCI_SOCK_RCV_VENDOR_PKT);
+ else
+ hci_sock_clear_flag(sk, HCI_SOCK_RCV_VENDOR_PKT);
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -2132,6 +2176,7 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname,
{
struct sock *sk = sock->sk;
int err = 0;
+ int opt_int;
u16 mtu;
BT_DBG("sk %p, opt %d", sk, optname);
@@ -2153,6 +2198,19 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname,
err = -EFAULT;
break;
+ case BT_RCV_VENDOR_PKT:
+ if (hci_pi(sk)->channel != HCI_CHANNEL_USER) {
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ opt_int = hci_sock_test_flag(sk, HCI_SOCK_RCV_VENDOR_PKT) ?
+ 1 : 0;
+ if (copy_to_iter(&opt_int, sizeof(opt_int),
+ &sopt->iter_out) != sizeof(opt_int))
+ err = -EFAULT;
+ break;
+
default:
err = -ENOPROTOOPT;
break;
---
base-commit: 7f02cdbb4cf17df8aa1977eea0cf490c472a706d
change-id: 20260719-support_vendor_hci-1fbb4449ab8e
Best regards,
--
Zijun Hu <zijun.hu@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH 1/1] Bluetooth: Fix parent socket UAF in accept queues
From: Ren Wei @ 2026-07-20 4:19 UTC (permalink / raw)
To: linux-bluetooth
Cc: marcel, luiz.dentz, kees, rollkingzzc, tim.bird, safa.karakus,
leitao, vega, xizh2024, enjou1224z
In-Reply-To: <cover.1784374481.git.xizh2024@lzu.edu.cn>
From: Zihan Xi <xizh2024@lzu.edu.cn>
Bluetooth children queued on a listening socket store the listener in
bt_sk(sk)->parent, but the accept queue did not hold a reference on that
parent socket. The child side can later fetch that pointer and unlink
itself from the accept queue while still needing to notify the listener,
for example from L2CAP, ISO or RFCOMM teardown/state-change callbacks.
If the listener is closed concurrently, removing the child from the
accept queue can drop the last listener reference before those callbacks
call parent->sk_data_ready(parent), leaving a stale parent pointer and a
use-after-free.
Take a reference on the parent when a child is queued and drop it when
the child is unlinked. Since unlinking now drops the accept-queue
parent reference, take a temporary parent reference in the callbacks that
continue to notify the parent after bt_accept_unlink().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
---
net/bluetooth/af_bluetooth.c | 2 ++
net/bluetooth/iso.c | 2 ++
net/bluetooth/l2cap_sock.c | 2 ++
net/bluetooth/rfcomm/sock.c | 2 ++
4 files changed, 8 insertions(+)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index a2290ffdc2c1..0cb745ce652d 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -217,6 +217,7 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
BT_DBG("parent %p, sk %p", parent, sk);
sock_hold(sk);
+ sock_hold(parent);
if (bh)
bh_lock_sock_nested(sk);
@@ -265,6 +266,7 @@ void bt_accept_unlink(struct sock *sk)
spin_unlock_bh(&bt_sk(parent)->accept_q_lock);
bt_sk(sk)->parent = NULL;
sock_put(sk);
+ sock_put(parent);
}
EXPORT_SYMBOL(bt_accept_unlink);
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index 2e95a153912c..a2ed9da0e42d 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -253,8 +253,10 @@ static void iso_chan_del(struct sock *sk, int err)
parent = bt_sk(sk)->parent;
if (parent) {
+ sock_hold(parent);
bt_accept_unlink(sk);
parent->sk_data_ready(parent);
+ sock_put(parent);
} else {
sk->sk_state_change(sk);
}
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 4058ff50cc27..3cd69cf26335 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1707,8 +1707,10 @@ static void l2cap_sock_teardown_cb(struct l2cap_chan *chan, int err)
sk->sk_err = err;
if (parent) {
+ sock_hold(parent);
bt_accept_unlink(sk);
parent->sk_data_ready(parent);
+ sock_put(parent);
} else {
sk->sk_state_change(sk);
}
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index feb302a491fa..4195816b4236 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -77,11 +77,13 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
parent = bt_sk(sk)->parent;
if (parent) {
+ sock_hold(parent);
if (d->state == BT_CLOSED) {
sock_set_flag(sk, SOCK_ZAPPED);
bt_accept_unlink(sk);
}
parent->sk_data_ready(parent);
+ sock_put(parent);
} else {
if (d->state == BT_CONNECTED)
rfcomm_session_getaddr(d->session,
--
2.43.0
^ permalink raw reply related
* [BUG] Bluetooth: btusb: poll_sync can fail to preserve HCI event/data ordering
From: Amir Abudubai @ 2026-07-20 0:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Luiz Augusto von Dentz, linux-kernel
Hello,
I encountered a bug that shows up as a GATT table discovery problem.
Client sees a GATT table resolved but empty. Eventually I tracked the
problem down to discovery failing when the peripheral drops the MTU
request for invalid handle because it arrives before the connection
complete event.
Digging deeper, the problem appears to be a bad assumption in btusb.c.
Its poll_sync assumes polling jitter is the only thing skewing the
arrival time between bulk and interrupt interfaces, which may be true
for some devices, but isn't typically true. I tested 3 different
devices and all 3 have different behaviors. An Intel adapter that is
async and guarantees interrupts arrive within 2 intervals, a
MediaTek([VID] [0e8d:0616]) that cannot recreate this bug because it
internally delays bulk until after interrupts have been delivered, and
a Realtek[7392] that synchronizes them, but always delivers interrupts
3.109 ms late. This is only a problem with the kernel configured to
1000Hz because of the minimum 1 jiffy delay in poll sync.
I made a test bench that recreates the bug while capturing logs. It
parses them and reports the time delta between MTU and Connection
Complete on both the USB and HCI.
https://github.com/Yes-it-was/btusb_interupt_bulk_sync_bench#
^ permalink raw reply
* RE: Bluetooth: hci_core: Explicitly kfree_skb() HCI_DRV_PKT and HCI_DIAG_PKT frames
From: bluez.test.bot @ 2026-07-19 21:44 UTC (permalink / raw)
To: linux-bluetooth, zijun.hu
In-Reply-To: <20260719-fix_hci_rx_work-v1-1-2d7fdeed3640@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2389 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=1130396
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint PASS 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.67 seconds
CheckAllWarning PASS 28.27 seconds
CheckSparse PASS 26.96 seconds
BuildKernel32 PASS 25.04 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 459.11 seconds
TestRunner_l2cap-tester PASS 58.81 seconds
TestRunner_iso-tester PASS 75.66 seconds
TestRunner_bnep-tester PASS 19.03 seconds
TestRunner_mgmt-tester FAIL 213.55 seconds
TestRunner_rfcomm-tester PASS 25.37 seconds
TestRunner_sco-tester PASS 31.16 seconds
TestRunner_ioctl-tester PASS 26.05 seconds
TestRunner_mesh-tester FAIL 26.01 seconds
TestRunner_smp-tester PASS 23.09 seconds
TestRunner_userchan-tester PASS 24.20 seconds
TestRunner_6lowpan-tester PASS 22.46 seconds
IncrementalBuild PASS 24.52 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
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.245 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.600 seconds
Mesh - Send cancel - 2 Timed out 1.992 seconds
https://github.com/bluez/bluetooth-next/pull/458
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: hci_core: Explicitly kfree_skb() HCI_DRV_PKT and HCI_DIAG_PKT frames
From: Zijun Hu @ 2026-07-19 20:29 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Zijun Hu
In hci_rx_work(), HCI_DRV_PKT and HCI_DIAG_PKT rely on the default
case to free them, and cause:
- They get mixed in with unknown packet types (default case).
- It is not clear which packet types the function is handling.
Fix by giving both their own case that kfree_skb()s explicitly.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
---
net/bluetooth/hci_core.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d1e78ae7728e..1e324c05af24 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4057,6 +4057,14 @@ static void hci_rx_work(struct work_struct *work)
hci_isodata_packet(hdev, skb);
break;
+ case HCI_DRV_PKT:
+ kfree_skb(skb);
+ break;
+
+ case HCI_DIAG_PKT:
+ kfree_skb(skb);
+ break;
+
default:
kfree_skb(skb);
break;
---
base-commit: bd8bee79e1fa8db2d587733f8b6fd9597b04d6e3
change-id: 20260719-fix_hci_rx_work-f03dd49d8ef8
Best regards,
--
Zijun Hu <zijun.hu@oss.qualcomm.com>
^ permalink raw reply related
* RE: Bluetooth: hci_sync: Protect UUID list traversal
From: bluez.test.bot @ 2026-07-19 17:48 UTC (permalink / raw)
To: linux-bluetooth, nicoyip.dev
In-Reply-To: <20260719162427.2902105-1-nicoyip.dev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2469 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=1130342
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 27.55 seconds
CheckAllWarning PASS 29.81 seconds
CheckSparse PASS 31.47 seconds
BuildKernel32 PASS 26.30 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 509.68 seconds
TestRunner_l2cap-tester PASS 60.47 seconds
TestRunner_iso-tester PASS 80.62 seconds
TestRunner_bnep-tester PASS 18.94 seconds
TestRunner_mgmt-tester FAIL 217.73 seconds
TestRunner_rfcomm-tester PASS 26.46 seconds
TestRunner_sco-tester PASS 32.41 seconds
TestRunner_ioctl-tester PASS 27.26 seconds
TestRunner_mesh-tester FAIL 26.97 seconds
TestRunner_smp-tester PASS 25.23 seconds
TestRunner_userchan-tester PASS 20.39 seconds
TestRunner_6lowpan-tester PASS 22.93 seconds
IncrementalBuild PASS 25.62 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 488 (98.8%), Failed: 2, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.257 seconds
LL Privacy - Unpair 1 Timed out 1.991 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.528 seconds
Mesh - Send cancel - 2 Timed out 1.988 seconds
https://github.com/bluez/bluetooth-next/pull/457
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: RFCOMM: Fix session UAF in set_termios
From: bluez.test.bot @ 2026-07-19 16:37 UTC (permalink / raw)
To: linux-bluetooth, nicoyip.dev
In-Reply-To: <20260719160311.2898053-1-nicoyip.dev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2389 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=1130329
---Test result---
Test Summary:
CheckPatch PASS 0.89 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.09 seconds
GitLint PASS 0.23 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 20.00 seconds
CheckAllWarning PASS 22.22 seconds
CheckSparse PASS 21.16 seconds
BuildKernel32 PASS 19.44 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 361.91 seconds
TestRunner_l2cap-tester PASS 47.05 seconds
TestRunner_iso-tester PASS 65.58 seconds
TestRunner_bnep-tester PASS 14.54 seconds
TestRunner_mgmt-tester FAIL 171.52 seconds
TestRunner_rfcomm-tester PASS 19.53 seconds
TestRunner_sco-tester PASS 26.52 seconds
TestRunner_ioctl-tester PASS 19.83 seconds
TestRunner_mesh-tester FAIL 20.50 seconds
TestRunner_smp-tester PASS 17.99 seconds
TestRunner_userchan-tester PASS 15.91 seconds
TestRunner_6lowpan-tester PASS 18.02 seconds
IncrementalBuild PASS 19.23 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
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.182 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 1.981 seconds
Mesh - Send cancel - 2 Timed out 1.993 seconds
https://github.com/bluez/bluetooth-next/pull/456
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: hci_sync: Protect UUID list traversal
From: Chengfeng Ye @ 2026-07-19 16:24 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, Chengfeng Ye, stable
The hci_sync conversion moved class-of-device and EIR generation from an
HCI request built under hdev->lock to asynchronous command sync work.
The worker holds hdev->req_lock, but that lock does not serialize access
to hdev->uuids against add_uuid() and remove_uuid(), which update the
list under hdev->lock.
The following interleaving can therefore occur:
CPU0 (command sync work) CPU1 (management socket)
fetch uuid from the list
list_del(&uuid->list)
kfree(uuid)
read uuid->size
KASAN reports the resulting use-after-free:
BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0
Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
eir_create+0xb8f/0xee0
hci_update_eir_sync+0x1c0/0x330
hci_cmd_sync_work+0x13c/0x290
process_one_work+0x63a/0x1070
worker_thread+0x45b/0xd10
Allocated by task 86:
__kasan_kmalloc+0x8f/0xa0
add_uuid+0x18a/0x4b0
hci_sock_sendmsg+0x1033/0x1ea0
Freed by task 92:
__kasan_slab_free+0x43/0x70
kfree+0x131/0x3c0
remove_uuid+0x25e/0x560
hci_sock_sendmsg+0x1033/0x1ea0
Hold hdev->lock while generating and committing the class-of-device and
EIR snapshots. Release it before sending an HCI command, so controller
waits do not happen under the device lock. This protects all UUID list
walks in these paths and restores the serialization lost in the command
sync conversion.
Fixes: 161510ccf91c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 1")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
---
net/bluetooth/hci_sync.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 532534bc601c..c0b1fc293b49 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -929,12 +929,16 @@ int hci_update_eir_sync(struct hci_dev *hdev)
memset(&cp, 0, sizeof(cp));
+ hci_dev_lock(hdev);
eir_create(hdev, cp.data);
- if (memcmp(cp.data, hdev->eir, sizeof(cp.data)) == 0)
+ if (memcmp(cp.data, hdev->eir, sizeof(cp.data)) == 0) {
+ hci_dev_unlock(hdev);
return 0;
+ }
memcpy(hdev->eir, cp.data, sizeof(cp.data));
+ hci_dev_unlock(hdev);
return __hci_cmd_sync_status(hdev, HCI_OP_WRITE_EIR, sizeof(cp), &cp,
HCI_CMD_TIMEOUT);
@@ -966,6 +970,7 @@ int hci_update_class_sync(struct hci_dev *hdev)
if (hci_dev_test_flag(hdev, HCI_SERVICE_CACHE))
return 0;
+ hci_dev_lock(hdev);
cod[0] = hdev->minor_class;
cod[1] = hdev->major_class;
cod[2] = get_service_classes(hdev);
@@ -973,8 +978,12 @@ int hci_update_class_sync(struct hci_dev *hdev)
if (hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE))
cod[1] |= 0x20;
- if (memcmp(cod, hdev->dev_class, 3) == 0)
+ if (memcmp(cod, hdev->dev_class, 3) == 0) {
+ hci_dev_unlock(hdev);
return 0;
+ }
+
+ hci_dev_unlock(hdev);
return __hci_cmd_sync_status(hdev, HCI_OP_WRITE_CLASS_OF_DEV,
sizeof(cod), cod, HCI_CMD_TIMEOUT);
--
2.43.0
^ permalink raw reply related
* [PATCH] Bluetooth: RFCOMM: Fix session UAF in set_termios
From: Chengfeng Ye @ 2026-07-19 16:03 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Kees Cook,
Jakub Kicinski, SeungJu Cheon, Chengfeng, Tim Bird, Pengpeng Hou,
Johan Hovold, Bastien Nocera, J. Suter, David S. Miller
Cc: linux-bluetooth, linux-kernel, Chengfeng Ye, stable
rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and
later passes the pointer to rfcomm_send_rpn(). The latter dereferences
both session->initiator and session->sock. Meanwhile, krfcommd can
unlink the DLC and free the session while holding rfcomm_mutex.
The race can proceed as follows:
TTY ioctl task krfcommd
-------------- --------
load dlc->session
enter rfcomm_send_rpn()
lock rfcomm_mutex
clear dlc->session
free session
unlock rfcomm_mutex
read session->initiator
KASAN reported:
BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0
Read of size 4 at addr ffff88810012a850 by task poc/92
Call Trace:
rfcomm_send_rpn+0x297/0x2a0
rfcomm_tty_set_termios+0x50d/0x850
tty_set_termios+0x596/0x950
set_termios+0x46a/0x6e0
tty_mode_ioctl+0x152/0xbd0
tty_ioctl+0x915/0x1240
__x64_sys_ioctl+0x134/0x1c0
Allocated by task 92:
rfcomm_session_add+0x9e/0x2e0
rfcomm_dlc_open+0x8b1/0xe00
rfcomm_dev_activate+0x85/0x1a0
rfcomm_tty_open+0x90/0x280
Freed by task 68:
kfree+0x131/0x3c0
rfcomm_session_del+0x119/0x180
rfcomm_run+0x737/0x4710
Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies
that the DLC is still attached and sends the RPN frame. Have the TTY
path use the helper and drop its unlocked session check. This keeps the
session valid through both the frame construction and socket send.
Fixes: 3a5e903c09ae ("[Bluetooth]: Implement RFCOMM remote port negotiation")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
---
include/net/bluetooth/rfcomm.h | 3 +++
net/bluetooth/rfcomm/core.c | 17 +++++++++++++++++
net/bluetooth/rfcomm/tty.c | 7 +++----
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index feb6b3ae5e69..102c278e3584 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -226,6 +226,9 @@ int rfcomm_send_rpn(struct rfcomm_session *s, int cr, u8 dlci,
u8 bit_rate, u8 data_bits, u8 stop_bits,
u8 parity, u8 flow_ctrl_settings,
u8 xon_char, u8 xoff_char, u16 param_mask);
+int rfcomm_dlc_send_rpn(struct rfcomm_dlc *d, u8 bit_rate, u8 data_bits,
+ u8 stop_bits, u8 parity, u8 flow_ctrl_settings,
+ u8 xon_char, u8 xoff_char, u16 param_mask);
/* ---- RFCOMM DLCs (channels) ---- */
struct rfcomm_dlc *rfcomm_dlc_alloc(gfp_t prio);
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index ebeae17b71d1..75f7512dec54 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1028,6 +1028,23 @@ int rfcomm_send_rpn(struct rfcomm_session *s, int cr, u8 dlci,
return rfcomm_send_frame(s, buf, ptr - buf);
}
+int rfcomm_dlc_send_rpn(struct rfcomm_dlc *d, u8 bit_rate, u8 data_bits,
+ u8 stop_bits, u8 parity, u8 flow_ctrl_settings,
+ u8 xon_char, u8 xoff_char, u16 param_mask)
+{
+ int err = -ENOTCONN;
+
+ rfcomm_lock();
+ if (d->session)
+ err = rfcomm_send_rpn(d->session, 1, d->dlci, bit_rate,
+ data_bits, stop_bits, parity,
+ flow_ctrl_settings, xon_char, xoff_char,
+ param_mask);
+ rfcomm_unlock();
+
+ return err;
+}
+
static int rfcomm_send_rls(struct rfcomm_session *s, int cr, u8 dlci, u8 status)
{
struct rfcomm_hdr *hdr;
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 4b9a699ec59b..b2c1060394e6 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -858,7 +858,7 @@ static void rfcomm_tty_set_termios(struct tty_struct *tty,
BT_DBG("tty %p termios %p", tty, old);
- if (!dev || !dev->dlc || !dev->dlc->session)
+ if (!dev || !dev->dlc)
return;
/* Handle turning off CRTSCTS */
@@ -979,9 +979,8 @@ static void rfcomm_tty_set_termios(struct tty_struct *tty,
}
if (changes)
- rfcomm_send_rpn(dev->dlc->session, 1, dev->dlc->dlci, baud,
- data_bits, stop_bits, parity,
- RFCOMM_RPN_FLOW_NONE, x_on, x_off, changes);
+ rfcomm_dlc_send_rpn(dev->dlc, baud, data_bits, stop_bits, parity,
+ RFCOMM_RPN_FLOW_NONE, x_on, x_off, changes);
}
static void rfcomm_tty_throttle(struct tty_struct *tty)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Sven Peter @ 2026-07-19 13:15 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Janne Grunau,
Marcel Holtmann, Luiz Augusto von Dentz
Cc: Neal Gompa, asahi, linux-arm-kernel, linux-bluetooth,
linux-kernel
In-Reply-To: <20260718172513.986134-2-u.kleine-koenig@baylibre.com>
On 7/18/26 19:25, Uwe Kleine-König (The Capable Hub) wrote:
> Initializing a struct using list initializers is hard to read, compared
> to that using named initializers is more ideomatic. Convert the macro
> used to assign values in the driver's pci_device_id array accordingly.
>
> This change doesn't introduce any changes to the compiled array on an
> x86 and an arm64 build.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
Acked-by: Sven Peter <sven@kernel.org>
Best,
Sven
^ permalink raw reply
* Re:Re: [PATCH v2] Bluetooth: HIDP: add missing length check for incoming frames
From: jiale yao @ 2026-07-19 5:37 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: <CABBYNZJdEjqd2eKmQNvPodvifnPgVvih5fnFf5sdA7Kpi7T19w@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 | 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;
- 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
^ permalink raw reply related
* Re: [RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Uwe Kleine-König @ 2026-07-18 21:52 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <6a5bbfe0.3cce8983.3cf542.f6be@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
Hello,
On Sat, Jul 18, 2026 at 11:03:12AM -0700, bluez.test.bot@gmail.com wrote:
> This is automated email and please do not reply to this email!
I disregard that because IMHO the judgement made here is misleading.
> 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=1130117
>
> ---Test result---
>
> Test Summary:
> CheckPatch PASS 0.56 seconds
> VerifyFixes PASS 0.09 seconds
> VerifySignedoff PASS 0.09 seconds
> GitLint FAIL 0.25 seconds
> SubjectPrefix PASS 0.09 seconds
> BuildKernel PASS 24.19 seconds
> CheckAllWarning PASS 27.46 seconds
> CheckSparse PASS 33.51 seconds
> BuildKernel32 PASS 24.60 seconds
> CheckKernelLLVM SKIP 0.00 seconds
> TestRunnerSetup PASS 442.54 seconds
> IncrementalBuild PASS 23.86 seconds
>
> Details
> ##############################
> Test: GitLint - FAIL
> Desc: Run gitlint
> Output:
> [RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
>
> 20: B2 Line has trailing whitespace: "or "
Indeed, however this is in the "cover" text that doesn't make it into
git. So I won't resend to fix that and hope you won't discard the patch
just because you see that FAIL.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: Don't auto-bond on reactive GATT security elevation
From: bluez.test.bot @ 2026-07-18 21:22 UTC (permalink / raw)
To: linux-bluetooth, pip
In-Reply-To: <20260718194230.35959-2-pip@pipobscure.com>
[-- Attachment #1: Type: text/plain, Size: 2823 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=1130150
---Test result---
Test Summary:
CheckPatch FAIL 0.71 seconds
GitLint PASS 0.46 seconds
BuildEll PASS 18.36 seconds
BluezMake PASS 653.95 seconds
MakeCheck PASS 18.62 seconds
MakeDistcheck PASS 147.18 seconds
CheckValgrind PASS 211.82 seconds
CheckSmatch PASS 248.24 seconds
bluezmakeextell PASS 91.53 seconds
IncrementalBuild PASS 1156.64 seconds
ScanBuild PASS 818.66 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,1/2] shared/att: don't auto-bond on reactive elevation
WARNING:BAD_SIGN_OFF: Non-standard signature: Assisted-by:
#107:
Assisted-by: Claude:Opus-4.8
ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Claude:Opus-4.8'
#107:
Assisted-by: Claude:Opus-4.8
/github/workspace/src/patch/14695485.patch total: 1 errors, 1 warnings, 73 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/14695485.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[BlueZ,2/2] unit/test-gatt: cover no-auto-sec on auth error
WARNING:BAD_SIGN_OFF: Non-standard signature: Assisted-by:
#81:
Assisted-by: Claude:Opus-4.8
ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Claude:Opus-4.8'
#81:
Assisted-by: Claude:Opus-4.8
/github/workspace/src/patch/14695486.patch total: 1 errors, 1 warnings, 46 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/14695486.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
https://github.com/bluez/bluez/pull/2330
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 45fc10: shared/att: don't auto-bond on reactive elevation
From: Philipp Dunkel @ 2026-07-18 20:25 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1130150
Home: https://github.com/bluez/bluez
Commit: 45fc1030b964091e556343571b76be0ca64be664
https://github.com/bluez/bluez/commit/45fc1030b964091e556343571b76be0ca64be664
Author: Philipp Dunkel <pip@pipobscure.com>
Date: 2026-07-18 (Sat, 18 Jul 2026)
Changed paths:
M src/device.c
M src/shared/att.c
M src/shared/att.h
Log Message:
-----------
shared/att: don't auto-bond on reactive elevation
When bluetoothd connects to a freshly discovered LE peer it probes it as
a GATT client through its built-in profiles (battery, mcp, ...). If one
of those reads a characteristic the peer has protected, the peer answers
with Insufficient Authentication (0x05). change_security() reacts to that
error by raising BT_SECURITY on the ATT socket, and on an unbonded LE
link raising security starts SMP pairing.
The result is a bond that nobody asked for: no user, no agent, and no
application requested it. It logs as a device_bonding_complete() bond
with a (nil) requestor, and the user is shown a pairing prompt for a
device that merely came into range and connected. On phones and laptops
that expose authentication-gated GATT characteristics this fires on
essentially every connection.
The existing opt-out cannot prevent it. change_security() only returns
early when chan->sec_level != BT_ATT_SECURITY_AUTO, but
bt_att_chan_set_security() records sec_level solely for BT_ATT_LOCAL
channels. An L2CAP/LE channel keeps its zero-initialised value (AUTO)
for its entire lifetime, so the guard never triggers and the link
always elevates.
Add bt_att_set_no_auto_sec(), a per-bt_att flag that makes
change_security() refuse to elevate. Set it from gatt_client_init() for
any connection that is neither bonded nor in a requested bonding, so a
speculative profile probe that hits an authentication-protected
characteristic fails on the auth error instead of silently pairing.
Devices being bonded via Pair() are unaffected: device->bonding is set
before the connection is established, so gatt_client_init() takes the
existing elevate-for-bonding branch and never sets the flag. Already
bonded devices are unaffected too: they are elevated proactively at
attach time when their LTK is available, and reconnections see
device_is_bonded() and skip the flag.
Tested against Android (Galaxy Z Flip 4), iOS (iPhone) and macOS
(MacBook): each connects and is probed by the built-in profiles with no
unsolicited pairing prompt, while explicit pairing continues to work.
Assisted-by: Claude:Opus-4.8
AI disclosure: this change was developed with the assistance of an AI
model (Claude Opus 4.8). The author reviewed every line. The fix was
built and exercised on real hardware -- against Android (Galaxy Z Flip
4), iOS (iPhone) and macOS (MacBook) peers -- and its behaviour was
observed directly, not inferred.
Commit: 4df3db7680e9da534458880a0b8a778a559a610f
https://github.com/bluez/bluez/commit/4df3db7680e9da534458880a0b8a778a559a610f
Author: Philipp Dunkel <pip@pipobscure.com>
Date: 2026-07-18 (Sat, 18 Jul 2026)
Changed paths:
M unit/test-gatt.c
Log Message:
-----------
unit/test-gatt: cover no-auto-sec on auth error
Add a regression test for bt_att_set_no_auto_sec(). The client reads a
characteristic and the peer answers with Insufficient Authentication
(0x05). Security is armed to BT_ATT_SECURITY_AUTO so a reactive elevation
would normally fire and retry the read, but no_auto_sec is set, so the
error must instead be delivered to the caller with no second request on
the wire.
This is the /auto variant (which does retry after elevating) with the
elevation forbidden. With the flag honoured the read fails once with
0x05; without it the client retries and the test aborts on the
unexpected Read Request, guarding the fix against regression.
Assisted-by: Claude:Opus-4.8
AI disclosure: this change was developed with the assistance of an AI
model (Claude Opus 4.8). The author reviewed every line. The test was
run against the built tree: it passes with patch 1 applied and was
confirmed to fail (client retries, harness aborts) without it.
Compare: https://github.com/bluez/bluez/compare/45fc1030b964%5E...4df3db7680e9
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ 2/2] unit/test-gatt: cover no-auto-sec on auth error
From: Philipp Dunkel @ 2026-07-18 19:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Philipp Dunkel
In-Reply-To: <20260718194230.35959-1-pip@pipobscure.com>
Add a regression test for bt_att_set_no_auto_sec(). The client reads a
characteristic and the peer answers with Insufficient Authentication
(0x05). Security is armed to BT_ATT_SECURITY_AUTO so a reactive elevation
would normally fire and retry the read, but no_auto_sec is set, so the
error must instead be delivered to the caller with no second request on
the wire.
This is the /auto variant (which does retry after elevating) with the
elevation forbidden. With the flag honoured the read fails once with
0x05; without it the client retries and the test aborts on the
unexpected Read Request, guarding the fix against regression.
Assisted-by: Claude:Opus-4.8
AI disclosure: this change was developed with the assistance of an AI
model (Claude Opus 4.8). The author reviewed every line. The test was
run against the built tree: it passes with patch 1 applied and was
confirmed to fail (client retries, harness aborts) without it.
---
unit/test-gatt.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/unit/test-gatt.c b/unit/test-gatt.c
index 535baaf..3929bb9 100644
--- a/unit/test-gatt.c
+++ b/unit/test-gatt.c
@@ -755,6 +755,22 @@ static void test_read(struct context *context)
test_read_cb, context, NULL));
}
+static void test_read_no_auto_sec(struct context *context)
+{
+ const struct test_step *step = context->data->step;
+
+ /* Arm reactive elevation (AUTO), then forbid it. An Insufficient
+ * Authentication error must be delivered to the caller instead of
+ * silently elevating security, which on a real unbonded link would
+ * start SMP bonding that nobody requested.
+ */
+ g_assert(bt_att_set_security(context->att, BT_ATT_SECURITY_AUTO));
+ bt_att_set_no_auto_sec(context->att, true);
+
+ g_assert(bt_gatt_client_read_value(context->client, step->handle,
+ test_read_cb, context, NULL));
+}
+
static const uint8_t read_data_1[] = {0x01, 0x02, 0x03};
static const struct test_step test_read_1 = {
@@ -795,6 +811,12 @@ static const struct test_step test_read_6 = {
.expected_att_ecode = 0x0c,
};
+static const struct test_step test_read_no_auto_sec_1 = {
+ .handle = 0x0003,
+ .func = test_read_no_auto_sec,
+ .expected_att_ecode = 0x05,
+};
+
static const struct test_step test_read_7 = {
.handle = 0x0004,
.func = test_read,
@@ -2803,6 +2825,12 @@ int main(int argc, char *argv[])
raw_pdu(0x0a, 0x03, 0x00),
raw_pdu(0x0b, 0x01, 0x02, 0x03));
+ define_test_client("/TP/GAR/CL/BI-04-C/no-auto-sec", test_client,
+ service_db_1, &test_read_no_auto_sec_1,
+ SERVICE_DATA_1_PDUS,
+ raw_pdu(0x0a, 0x03, 0x00),
+ raw_pdu(0x01, 0x0a, 0x03, 0x00, 0x05));
+
define_test_client("/TP/GAR/CL/BI-05-C", test_client, service_db_1,
&test_read_6,
SERVICE_DATA_1_PDUS,
--
2.55.0
^ permalink raw reply related
* [PATCH BlueZ 1/2] shared/att: don't auto-bond on reactive elevation
From: Philipp Dunkel @ 2026-07-18 19:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Philipp Dunkel
In-Reply-To: <20260718194230.35959-1-pip@pipobscure.com>
When bluetoothd connects to a freshly discovered LE peer it probes it as
a GATT client through its built-in profiles (battery, mcp, ...). If one
of those reads a characteristic the peer has protected, the peer answers
with Insufficient Authentication (0x05). change_security() reacts to that
error by raising BT_SECURITY on the ATT socket, and on an unbonded LE
link raising security starts SMP pairing.
The result is a bond that nobody asked for: no user, no agent, and no
application requested it. It logs as a device_bonding_complete() bond
with a (nil) requestor, and the user is shown a pairing prompt for a
device that merely came into range and connected. On phones and laptops
that expose authentication-gated GATT characteristics this fires on
essentially every connection.
The existing opt-out cannot prevent it. change_security() only returns
early when chan->sec_level != BT_ATT_SECURITY_AUTO, but
bt_att_chan_set_security() records sec_level solely for BT_ATT_LOCAL
channels. An L2CAP/LE channel keeps its zero-initialised value (AUTO)
for its entire lifetime, so the guard never triggers and the link
always elevates.
Add bt_att_set_no_auto_sec(), a per-bt_att flag that makes
change_security() refuse to elevate. Set it from gatt_client_init() for
any connection that is neither bonded nor in a requested bonding, so a
speculative profile probe that hits an authentication-protected
characteristic fails on the auth error instead of silently pairing.
Devices being bonded via Pair() are unaffected: device->bonding is set
before the connection is established, so gatt_client_init() takes the
existing elevate-for-bonding branch and never sets the flag. Already
bonded devices are unaffected too: they are elevated proactively at
attach time when their LTK is available, and reconnections see
device_is_bonded() and skip the flag.
Tested against Android (Galaxy Z Flip 4), iOS (iPhone) and macOS
(MacBook): each connects and is probed by the built-in profiles with no
unsolicited pairing prompt, while explicit pairing continues to work.
Assisted-by: Claude:Opus-4.8
AI disclosure: this change was developed with the assistance of an AI
model (Claude Opus 4.8). The author reviewed every line. The fix was
built and exercised on real hardware -- against Android (Galaxy Z Flip
4), iOS (iPhone) and macOS (MacBook) peers -- and its behaviour was
observed directly, not inferred.
---
src/device.c | 13 +++++++++++++
src/shared/att.c | 20 ++++++++++++++++++++
src/shared/att.h | 1 +
3 files changed, 34 insertions(+)
diff --git a/src/device.c b/src/device.c
index 65d84be..821a834 100644
--- a/src/device.c
+++ b/src/device.c
@@ -6301,6 +6301,7 @@ static void gatt_debug(const char *str, void *user_data)
static void gatt_client_init(struct btd_device *device)
{
uint8_t features;
+ bool unbonded;
gatt_client_cleanup(device);
@@ -6319,9 +6320,21 @@ static void gatt_client_init(struct btd_device *device)
if (btd_opts.gatt_channels > 1)
features |= BT_GATT_CHRC_CLI_FEAT_EATT;
+ unbonded = !device_is_bonded(device, device->bdaddr_type);
+
if (!btd_opts.gatt_seclevel && device->bonding) {
DBG("Elevating security level since bonding is in progress");
bt_att_set_security(device->att, BT_ATT_SECURITY_MEDIUM);
+ } else if (!btd_opts.gatt_seclevel && unbonded) {
+ /* No bond exists and none is being requested, so no
+ * user or agent has consented to pairing. Forbid a
+ * reactive security elevation: a speculative GATT
+ * profile probe (battery, MCP, ...) that reads an
+ * auth-protected characteristic must fail rather than
+ * silently initiating SMP bonding nobody asked for.
+ */
+ DBG("Unbonded link: no reactive GATT elevation");
+ bt_att_set_no_auto_sec(device->att, true);
}
device->client = bt_gatt_client_new(device->db, device->att,
diff --git a/src/shared/att.c b/src/shared/att.c
index 3d3c8cf..c42a521 100644
--- a/src/shared/att.c
+++ b/src/shared/att.c
@@ -92,6 +92,10 @@ struct bt_att {
struct sign_info *local_sign;
struct sign_info *remote_sign;
+
+ bool no_auto_sec; /* Never reactively elevate security
+ * (would initiate an unrequested bond)
+ */
};
struct sign_info {
@@ -766,6 +770,14 @@ static bool change_security(struct bt_att_chan *chan, uint8_t ecode)
{
int security;
+ /* A reactive elevation on an unbonded link starts SMP bonding.
+ * When the owner has forbidden auto-elevation (no_auto_sec), a
+ * speculative GATT profile probe that reads an auth-protected
+ * characteristic must fail here rather than silently pair.
+ */
+ if (chan->att->no_auto_sec)
+ return false;
+
if (chan->sec_level != BT_ATT_SECURITY_AUTO)
return false;
@@ -2103,6 +2115,14 @@ bool bt_att_set_security(struct bt_att *att, int level)
return bt_att_chan_set_security(chan, level);
}
+void bt_att_set_no_auto_sec(struct bt_att *att, bool value)
+{
+ if (!att)
+ return;
+
+ att->no_auto_sec = value;
+}
+
void bt_att_set_enc_key_size(struct bt_att *att, uint8_t enc_size)
{
if (!att)
diff --git a/src/shared/att.h b/src/shared/att.h
index ba1f846..3dbfe86 100644
--- a/src/shared/att.h
+++ b/src/shared/att.h
@@ -112,6 +112,7 @@ bool bt_att_unregister_all(struct bt_att *att);
int bt_att_get_security(struct bt_att *att, uint8_t *enc_size);
bool bt_att_set_security(struct bt_att *att, int level);
+void bt_att_set_no_auto_sec(struct bt_att *att, bool value);
void bt_att_set_enc_key_size(struct bt_att *att, uint8_t enc_size);
bool bt_att_set_local_key(struct bt_att *att, uint8_t sign_key[16],
--
2.55.0
^ permalink raw reply related
* [PATCH BlueZ 0/2] Don't auto-bond on reactive GATT security elevation
From: Philipp Dunkel @ 2026-07-18 19:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Philipp Dunkel
bluetoothd probes every freshly connected LE peer as a GATT client
through its built-in profiles (battery, mcp, ...). When such a probe
reads a characteristic the peer has protected, the peer answers with
Insufficient Authentication (0x05), and change_security() reacts by
raising BT_SECURITY on the ATT socket. On an unbonded LE link that
starts SMP pairing, so the user is shown a pairing prompt for a device
that merely came into range -- a bond nobody requested, logged as a
device_bonding_complete() bond with a (nil) requestor.
The existing opt-out does not help: change_security() only bails when
chan->sec_level != BT_ATT_SECURITY_AUTO, but sec_level is recorded for
BT_ATT_LOCAL channels only, so an L2CAP/LE channel stays at AUTO for its
whole lifetime and always elevates.
Patch 1 adds bt_att_set_no_auto_sec(), a per-bt_att flag that makes
change_security() refuse to elevate, and sets it from gatt_client_init()
for any link that is neither bonded nor in a requested bonding.
In-progress Pair() and already-bonded devices keep their existing
elevation paths untouched.
Patch 2 adds a unit test: it arms AUTO security and then forbids
elevation, asserting the auth error is delivered to the caller with no
retry on the wire. Without patch 1 the client retries and the test
aborts on the unexpected Read Request.
Tested against Android (Galaxy Z Flip 4), iOS (iPhone) and macOS
(MacBook): each connects and is probed with no unsolicited pairing
prompt, while explicit pairing continues to work.
Both patches were developed with the assistance of an AI model
(Claude Opus 4.8), disclosed per-patch with an Assisted-by: trailer.
Every line was reviewed by me and the result was built, run and tested
on the hardware above -- behaviour observed, not inferred.
Philipp Dunkel (2):
shared/att: don't auto-bond on reactive elevation
unit/test-gatt: cover no-auto-sec on auth error
src/device.c | 13 +++++++++++++
src/shared/att.c | 20 ++++++++++++++++++++
src/shared/att.h | 1 +
unit/test-gatt.c | 28 ++++++++++++++++++++++++++++
4 files changed, 62 insertions(+)
--
2.55.0
^ permalink raw reply
* RE: [RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: bluez.test.bot @ 2026-07-18 18:03 UTC (permalink / raw)
To: linux-bluetooth, u.kleine-koenig
In-Reply-To: <20260718172513.986134-2-u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1383 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=1130117
---Test result---
Test Summary:
CheckPatch PASS 0.56 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.09 seconds
GitLint FAIL 0.25 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 24.19 seconds
CheckAllWarning PASS 27.46 seconds
CheckSparse PASS 33.51 seconds
BuildKernel32 PASS 24.60 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 442.54 seconds
IncrementalBuild PASS 23.86 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
20: B2 Line has trailing whitespace: "or "
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/455
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH RESEND] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-18 17:25 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Marcel Holtmann, Luiz Augusto von Dentz
Cc: Neal Gompa, asahi, linux-arm-kernel, linux-bluetooth,
linux-kernel
Initializing a struct using list initializers is hard to read, compared
to that using named initializers is more ideomatic. Convert the macro
used to assign values in the driver's pci_device_id array accordingly.
This change doesn't introduce any changes to the compiled array on an
x86 and an arm64 build.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
it seems in the bluetooth patchwork patches are archived automatically
after a month. And that even if there is recent activity. I consider
that very annoying for contributors.
So to get back on the list of considered patches, here comes a resend.
The original submission can be found at
https://lore.kernel.org/linux-bluetooth/20260504160940.2168650-2-u.kleine-koenig@baylibre.com
or
https://patchwork.kernel.org/project/bluetooth/patch/20260504160940.2168650-2-u.kleine-koenig@baylibre.com/
.
Best regards
Uwe
drivers/bluetooth/hci_bcm4377.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..89c317561bfb 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2525,11 +2525,12 @@ static const struct bcm4377_hw bcm4377_hw_variants[] = {
},
};
-#define BCM4377_DEVID_ENTRY(id) \
- { \
- PCI_VENDOR_ID_BROADCOM, BCM##id##_DEVICE_ID, PCI_ANY_ID, \
- PCI_ANY_ID, PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, \
- BCM##id \
+#define BCM4377_DEVID_ENTRY(id) \
+ { \
+ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BCM ## id ## _DEVICE_ID), \
+ .class = PCI_CLASS_NETWORK_OTHER << 8, \
+ .class_mask = 0xffff00, \
+ .driver_data = BCM ## id, \
}
static const struct pci_device_id bcm4377_devid_table[] = {
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* RE: Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: bluez.test.bot @ 2026-07-18 17:00 UTC (permalink / raw)
To: linux-bluetooth, u.kleine-koenig
In-Reply-To: <20260504160940.2168650-2-u.kleine-koenig@baylibre.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=1089397
---Test result---
Test Summary:
CheckPatch PASS 0.75 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.35 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.64 seconds
CheckAllWarning PASS 28.11 seconds
CheckSparse PASS 26.77 seconds
BuildKernel32 PASS 25.05 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 467.42 seconds
IncrementalBuild PASS 24.68 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/454
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: bluez.test.bot @ 2026-07-18 15:08 UTC (permalink / raw)
To: linux-bluetooth, u.kleine-koenig
In-Reply-To: <20260504160940.2168650-2-u.kleine-koenig@baylibre.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=1089397
---Test result---
Test Summary:
CheckPatch PASS 0.76 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.35 seconds
SubjectPrefix PASS 0.14 seconds
BuildKernel PASS 26.95 seconds
CheckAllWarning PASS 29.53 seconds
CheckSparse PASS 28.28 seconds
BuildKernel32 PASS 26.89 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 510.75 seconds
IncrementalBuild PASS 25.94 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/453
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221720] Outdated Intel BT firmware ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq (patch 0x27) breaks all HFP/SCO audio — Windows driver ships working patch 0x2b
From: bugzilla-daemon @ 2026-07-18 15:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221720-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221720
--- Comment #2 from dev@fluid8.de (dev@fluid8.de) ---
Created attachment 310476
--> https://bugzilla.kernel.org/attachment.cgi?id=310476&action=edit
install Intel Bluetooth legacy RAM-patch firmware
install-ibt-fw.sh — install Intel Bluetooth legacy RAM-patch firmware.
Companion to extract-ibt-fw.py: takes the .bseq blobs that script carved out of
Intel's Windows driver and installs them so the Linux btintel driver picks them
up, on any reasonably current Linux distribution.
# ./extract-ibt-fw.py --verify BT_21.10.1_64_Win8.1.exe out/
# sudo ./install-ibt-fw.sh out/
# # then power the machine fully off once
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-18 14:08 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Markus Schneider-Pargmann, asahi, linux-arm-kernel,
linux-bluetooth, linux-kernel
In-Reply-To: <ainSCcYroJUIAuwr@monoceros>
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
On Wed, Jun 10, 2026 at 11:08:49PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> On Wed, Jun 10, 2026 at 01:13:44PM -0400, Luiz Augusto von Dentz wrote:
> > On Wed, Jun 10, 2026 at 12:59 PM Uwe Kleine-König (The Capable Hub)
> > <u.kleine-koenig@baylibre.com> wrote:
> > >
> > > On Mon, May 04, 2026 at 06:09:40PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > > Initializing a struct using list initializers is hard to read, compared
> > > > to that using named initializers is more ideomatic. Convert the macro
> > > > used to assign values in the driver's pci_device_id array accordingly.
> > > >
> > > > This change doesn't introduce any changes to the compiled array on an
> > > > x86 and an arm64 build.
> > > >
> > > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > > > ---
> > > > Hello,
> > > >
> > > > this is a preparing change for making struct pci_device_id::driver_data an
> > > > anonymous union (similar to
> > > > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
> > > > This requires named initializers for .driver_data. But even without that
> > > > this is a nice cleanup making the macro better readable.
> > > >
> > > > Gcc is happy with simplifying the assignment further using
> > > > PCI_VDEVICE(BROADCOM, BCM ## id ## _DEVICE_ID), but this is a bit fishy
> > > > because PCI_VDEVICE also assigns .class and .class_mask (using list
> > > > initializers), so I didn't convert that.
> > >
> > > In the meantime I learned that doing that would break W=1 builds, so it
> > > was a good choice to not go that path.
> > >
> > > > Once all pci_device_id use
> > > > named initializers, the two zeros can be dropped from PCI_VDEVICE and
> > > > this entry simplified accordingly.
> > >
> > > Is this patch still on someone's radar? Ideally for application in time
> > > for 7.2-rc1?
> >
> > It is no longer in patchwork so if you really want to get in please resend.
>
> Instead I unarchived the patch, so it appears in the patch list again. I
> hope this is easier for everyone (it is for me).
That didn't help, it is archived again. So I'll resend, but I still
wonder about the processes involved. Is there a bogous automation that
archives patches after a while? Or is someone archiving patches by hand
that look old? Both make patchwork as tracker somewhat useless ...
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Bug 221720] Outdated Intel BT firmware ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq (patch 0x27) breaks all HFP/SCO audio — Windows driver ships working patch 0x2b
From: bugzilla-daemon @ 2026-07-18 13:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221720-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221720
--- Comment #1 from dev@fluid8.de (dev@fluid8.de) ---
Created attachment 310475
--> https://bugzilla.kernel.org/attachment.cgi?id=310475&action=edit
extract bluetooth firmware from window driver files
With this script:
python3 extract-ibt-fw.py [--verify] BT_21.10.1_64_Win8.1.exe [output-dir]
you can extract the firmware binary and use it on Linux.
The script als0 checks if the SHA-sum of the extract file matches the expected
one.
You also need the Windows driver files. Intel doesn't provide a public download
link anymore.
The Firmware is in this file:
BT_21.10.1_64_Win8.1.exe
Download link for this file:
https://drivers.softpedia.com/get/BLUETOOTH/Intel/Intel-Wireless-Bluetooth-Driver-21-10-1-for-Windows-10-64-bit.shtml
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* xHCI TT: FS audio capture glitches when btusb SCO runs concurrently
From: Branislav Klocok @ 2026-07-18 10:18 UTC (permalink / raw)
To: linux-usb; +Cc: linux-bluetooth, mathias.nyman
Hi,
I'd like to report (and ask for guidance on) an apparent conflict between
two concurrent full-speed isochronous streams on the same xHCI controller:
a full-speed USB audio device behind a hub (split transactions through the
hub's TT) and the SCO endpoints of an Intel Bluetooth controller (btusb)
on a root port.
Short version: while an HFP call is active over Bluetooth (SCO), the
capture stream of a full-speed USB headset plugged in *behind a dock hub*
is subtly corrupted. After mSBC encoding and the telephony path, the far
end hears severely "robotic" audio. Moving the same headset to a direct
root port makes the problem disappear immediately; moving it back behind
the dock brings it back. CVSD calls are perceptually unaffected.
Environment
-----------
- ThinkPad X1 Carbon 6th gen; xHCI: Intel Sunrise Point-LP [8086:9d2f]
- Kernel 7.1.3-1-default (openSUSE Tumbleweed), BlueZ 5.82,
PipeWire 1.6.8 / WirePlumber 0.5.15 (HFP native backend, laptop = HF)
- Bluetooth: Intel 8265 [8087:0a2b], full-speed, internal (bus 1 root
port 7), fw ibt-12-16
- USB headset: C-Media [0d8c:0014], full-speed, mono capture 48 kHz
- Dock: Lenovo USB dock (hubs 17ef:3071/17ef:3070, cascade incl.
067b:2586 and 05e3:0610)
- HFP counterpart: Android phone (Volla X23) as AG; a call was placed to
a second handset held at my ear, so I judged the far-end quality
directly while speaking
SCO detail during mSBC: eSCO, air mode Transparent, 60-byte RX/TX packet
length, btusb isoc alt setting 1 (9-byte packets), HCI SCO frames
dlen 24. CVSD uses alt setting 2 (17-byte packets).
Reproduction (single call, changing only the capture source / port)
-------------------------------------------------------------------
I kept the same position and speech style throughout and judged the
quality on the far-end handset:
uplink capture source far-end verdict
1. HS webcam (behind the same dock) clean
2. FS headset behind dock hub A severely "robotic"
3. same, headset moved 30 cm away severely "robotic"
(rules out mic proximity/level)
4. FS headset on a DIRECT root port clean
5. FS headset behind dock hub B severely "robotic" again
(immediately reversible)
A parallel capture of the same source during phase 5 (recording to a file
while the stream also feeds the call) contains audible subtle glitching
already at the capture side -- i.e. the corruption exists in the USB
capture data before any Bluetooth/mSBC processing. Amplitude analysis
shows no zero-runs or full-scale clicks, so the defect consists of small
sample-level discontinuities, which the frame-based mSBC codec then
amplifies into severe artifacts, while sample-based CVSD mostly masks
them.
What I ruled out
----------------
- Bluetooth host stack: btmon traces covering a clean -> robotic -> clean
cycle show the HCI SCO TX stream is byte-perfect (intact 60-byte mSBC
framing with H2 headers, ~3333 frames/10 s constant) and the write
timing pattern is identical between clean and robotic phases (bursts of
3x24 B every ~7.5 ms). The RX direction is likewise clean. So
BlueZ/PipeWire/btusb submit correct data on time; the corruption
happens elsewhere.
- Audio content/level: same speech, same position (phase 3).
- The specific adapter/hub: reproduced behind two different hub chains,
and with a different FS combo headset (Sennheiser) behind a different
(Thunderbolt) dock in another location -- there the mSBC *downlink*
died completely while CVSD kept working.
- PipeWire graph effects: an *idle* parallel capture from the FS device
behind the dock (both via PipeWire and via direct ALSA hw:) does NOT
disturb a call whose uplink comes from the HS webcam -- the corruption
only matters when the TT capture stream is the one feeding the call.
Consistent with the corruption being on the TT capture stream itself.
Possibly related: "Bluetooth: hci0: corrupted SCO packet" bursts (~14-32
messages) at SCO setup time, with both codecs, transient. Earlier this
year, on 6.18.8 with the Thunderbolt dock setup, mSBC showed frequent
decode errors but audio still flowed; I have not bisected.
Questions
---------
1. Is this a known limitation of xHCI TT split-isochronous scheduling
with two concurrent FS isoc streams (one behind a TT, one on a root
port)? EHCI had a software TT scheduler
(CONFIG_USB_EHCI_TT_NEWSCHED); as far as I can tell xHCI relies on
hardware scheduling with no equivalent knob.
2. Which captures would help most? I can provide btmon traces (a 26 MB
clean/robotic cycle), usbmon captures, xhci dynamic debug logs and
audio samples, and I'm happy to test patches.
Best regards,
--
Branislav Klocok
email: branislav.klocok@orava.sk
tel: +421908703366
^ 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