* Re: [PATCH] Bluetooth: L2CAP: validate connectionless PSM length
From: patchwork-bot+bluetooth @ 2026-06-10 15:40 UTC (permalink / raw)
To: Samuel Moelius; +Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260608235705.1233510.fe2269cf0103.bluetooth-l2cap-connless-short-pdu-oob@trailofbits.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 8 Jun 2026 23:57:05 +0000 you wrote:
> Connectionless L2CAP frames carry a two-byte PSM at the start of the
> payload. l2cap_recv_frame() currently reads that PSM unconditionally
> after validating only the outer L2CAP length.
>
> A malformed connectionless frame with a zero- or one-byte payload can
> therefore make the parser read beyond the advertised skb payload and use
> tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer
> injected a one-byte connectionless payload and reached the unchecked
> read.
>
> [...]
Here is the summary with links:
- Bluetooth: L2CAP: validate connectionless PSM length
https://git.kernel.org/bluetooth/bluetooth-next/c/801f756504d1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci: validate codec capability element length
From: patchwork-bot+bluetooth @ 2026-06-10 15:40 UTC (permalink / raw)
To: Samuel Moelius; +Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260608235627.1233330.bc5338ecae62.bluetooth-hci-codec-cap-short-oob@trailofbits.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 8 Jun 2026 23:56:28 +0000 you wrote:
> Read Local Codec Capabilities returns a sequence of capability elements.
> Each element starts with a one-byte length followed by that many payload
> bytes.
>
> hci_read_codec_capabilities() checks that the skb contains the length
> byte, but then validates only caps->len against the remaining skb
> length. A malformed controller response with one remaining byte and
> caps->len set to one passes that check even though the element needs two
> bytes. The parser then records a two-byte capability and copies one
> byte beyond the advertised response payload into the codec list.
>
> [...]
Here is the summary with links:
- Bluetooth: hci: validate codec capability element length
https://git.kernel.org/bluetooth/bluetooth-next/c/246dc2ed724b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hci_codec: validate capability record length
From: patchwork-bot+bluetooth @ 2026-06-10 15:40 UTC (permalink / raw)
To: Ren Wei
Cc: linux-bluetooth, marcel, luiz.dentz, kiran.k,
chethan.tumkur.narayan, ravishankar.srivatsa, yuantan098,
zcliangcn, bird, xuyq21
In-Reply-To: <4927cae4fe043f3e2aa80f4ee6bed05e4fb5a6d4.1779633761.git.xuyq21@lenovo.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Fri, 29 May 2026 21:12:25 +0800 you wrote:
> From: Yuqi Xu <xuyq21@lenovo.com>
>
> hci_read_codec_capabilities() validates each capability entry before
> adding its serialized size to len and advancing the skb.
>
> The current check only compares skb->len against caps->len, even
> though the code consumes the length byte and the payload. Validate
> the full record size so the cached capability length matches the
> bytes available in the command response.
>
> [...]
Here is the summary with links:
- [1/1] Bluetooth: hci_codec: validate capability record length
https://git.kernel.org/bluetooth/bluetooth-next/c/246dc2ed724b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Siwei Zhang @ 2026-06-10 15:34 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth, Luiz Augusto von Dentz
In-Reply-To: <9771585a101e05bb020e374f69c18d9198964fec.camel@iki.fi>
Hi Pauli,
On Wed, Jun 10, 2026, at 11:21 AM, Pauli Virtanen wrote:
> Hi,
>
> ke, 2026-06-10 kello 10:02 -0400, Luiz Augusto von Dentz kirjoitti:
>> Hi Siwei,
>>
>> On Wed, Jun 10, 2026 at 9:52 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>> >
>> > Hi Luiz,
>> >
>> > On Wed, Jun 10, 2026, at 9:14 AM, Luiz Augusto von Dentz wrote:
>> > > Hi Siwei,
>> > >
>> > > On Wed, Jun 10, 2026 at 9:07 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>> > > >
>> > > > hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
>> > > > is pending, but hdev->sent_cmd can be NULL while req_status is still
>> > > > HCI_REQ_PEND
>> > >
>> > > Can it really be NULL? If it can then I don't think we are handling
>> > > HCI_REQ_PEND well and perhaps should instead just check hdev->sent_cmd
>> > > directly instead of bothering with hdev->req_status.
>> > >
>> >
>> > This is the crash stack.
>> >
>> > Title: general protection fault in hci_abort_conn
>> > Type: general protection fault
>> > Function: hci_abort_conn
>> > Signature: f64ebf7af5cee01a
>> > Time: 2026-06-01-12:48:57
>> > ---
>> > [ 1266.952280] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
>> > [ 1266.954486] KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
>> > [ 1266.955864] CPU: 0 UID: 0 PID: 384 Comm: kworker/u9:1 Tainted: G W 7.0.8-g8de79710cf39 #4 PREEMPT(lazy)
>> > [ 1266.957695] Tainted: [W]=WARN
>> > [ 1266.958535] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>> > [ 1266.960480] Workqueue: hci0 hci_rx_work
>> > [ 1266.961483] RIP: 0010:hci_abort_conn+0x179/0x2d0
>> > [ 1266.962296] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
>> > [ 1266.965380] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
>> > [ 1266.966267] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
>> > [ 1266.967770] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
>> > [ 1266.969054] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
>> > [ 1266.970874] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
>> > [ 1266.972036] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
>> > [ 1266.973213] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
>> > [ 1266.974917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [ 1266.975867] CR2: 00007f51ba4e2020 CR3: 000000010fea7000 CR4: 00000000000006f0
>> > [ 1266.977409] Call Trace:
>> > [ 1266.977895] <TASK>
>> > [ 1266.978676] hci_disconnect+0xe8/0x250 net/bluetooth/hci_conn.c:197
>> > [ 1266.979781] ? lock_release+0xf8/0x370 kernel/locking/lockdep.c:5889
>> > [ 1266.980541] ? __pfx_hci_disconnect+0x10/0x10 net/bluetooth/hci_conn.c:179
>> > [ 1266.981926] ? hci_conn_hash_lookup_ba+0x29e/0x2c0 include/net/bluetooth/hci_core.h:1259
>> > [ 1266.982879] ? __crypto_memneq+0x47/0x490 lib/crypto/memneq.c:169
>> > [ 1266.983884] hci_link_key_notify_evt+0x21d/0xa50 net/bluetooth/hci_event.c:4750
>> > [ 1266.984987] ? __pfx___mutex_unlock_slowpath+0x10/0x10 kernel/locking/mutex.c:932
>> > [ 1266.985918] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
>> > [ 1266.986769] ? skb_pull_data+0x100/0x1b0 net/core/skbuff.c:2710
>> > [ 1266.987754] hci_event_packet+0x65e/0xd50
>> > [ 1266.988429] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
>> > [ 1266.989277] ? __pfx_hci_event_packet+0x10/0x10 net/bluetooth/hci_event.c:7803
>> > [ 1266.990051] ? lockdep_hardirqs_on_prepare+0x168/0x230 kernel/locking/lockdep.c:4410
>> > [ 1266.991088] ? hci_send_to_monitor+0xdd/0x510
>> > [ 1266.991977] hci_rx_work+0x3d1/0x8d0 net/bluetooth/hci_core.c:4078
>> > [ 1266.993050] ? process_scheduled_works+0xa01/0x1760 kernel/workqueue.c:3371
>> > [ 1266.994019] process_scheduled_works+0xac1/0x1760 kernel/workqueue.c:3371
>> > [ 1266.995274] ? trace_sched_exit_tp+0x35/0x130 include/trace/events/sched.h:886
>> > [ 1266.996155] ? __pfx_process_scheduled_works+0x10/0x10 kernel/workqueue.c:3361
>> > [ 1266.997132] ? do_raw_spin_lock+0x126/0x270 kernel/locking/spinlock_debug.c:116
>> > [ 1266.997955] ? assign_work+0x333/0x4d0
>> > [ 1266.998706] worker_thread+0xa22/0xf80 kernel/workqueue.c:3453
>> > [ 1266.999792] ? __kthread_parkme+0x1a5/0x200
>> > [ 1267.000591] kthread+0x38b/0x480 kernel/kthread.c:438
>> > [ 1267.001680] ? __pfx_worker_thread+0x10/0x10 kernel/workqueue.c:3398
>> > [ 1267.002499] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
>> > [ 1267.003154] ret_from_fork+0x436/0x950 arch/x86/kernel/process.c:164
>> > [ 1267.003797] ? __pfx_ret_from_fork+0x10/0x10 arch/x86/kernel/process.c:153
>> > [ 1267.004501] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
>> > [ 1267.005137] ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:258
>> > [ 1267.005855] </TASK>
>> > [ 1267.006918] Modules linked in:
>> > [ 1267.008266] ---[ end trace 0000000000000000 ]---
>> > [ 1267.010119] RIP: 0010:hci_abort_conn+0x179/0x2d0
>> > [ 1267.011723] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
>> > [ 1267.015717] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
>> > [ 1267.016793] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
>> > [ 1267.018342] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
>> > [ 1267.019857] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
>> > [ 1267.021481] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
>> > [ 1267.022973] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
>> > [ 1267.024217] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
>> > [ 1267.025954] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> >
>> > > > , leading to a NULL pointer dereference and a general
>> > > > protection fault from the hci_rx_work() receive path.
>> > > >
>> > > > Check hdev->sent_cmd before dereferencing it.
>> > > >
>> > > > Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
>> > > > Cc: stable@vger.kernel.org
>> > > > Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
>> > > > ---
>> > > > net/bluetooth/hci_conn.c | 3 ++-
>> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> > > > index 54eabaa46960..43fdacb2c9b2 100644
>> > > > --- a/net/bluetooth/hci_conn.c
>> > > > +++ b/net/bluetooth/hci_conn.c
>> > > > @@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
>> > > > * hci_connect_le serializes the connection attempts so only one
>> > > > * connection can be in BT_CONNECT at time.
>> > > > */
>> > > > - if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
>> > > > + if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
>> > > > + hdev->sent_cmd) {
>> > > > switch (hci_skb_event(hdev->sent_cmd)) {
>
> The hdev->sent_cmd access here looks unsafe vs synchronization:
>
> * hdev->sent_cmd pointer is modified (only) from hci_cmd_work() which
> runs in hdev->workqueue.
>
> * No lock is held, only the ordered hdev->workqueue synchronizes
>
> * The skb pointed to is also freed from hdev->workqueue.
>
> * Even if valid pointer to it is obtained, the skb may be freed under
> us here
>
> hci_abort_conn() is called from places like smp->security_timer ->
> hci_disconnect() which run in kernel default workqueues -> potential
> UAF here.
>
> MGMT unpair_device_sync() appears to call it from hdev->req_workqueue,
> which is then the same.
>
> Taking hdev_lock doesn't help here, as it's only synchronized by the
> workqueue.
>
> The hdev->sent_cmd probably needs some new locking primitive, not sure
> hdev->lock and hdev->req_lock can be used here as not sure what locking
> contexts this is called from.
>
Thanks for your review. The patch v2 eliminate hdev->sent_cmd
access here. Please check:
https://lore.kernel.org/linux-bluetooth/20260610150704.1234558-1-oss@fourdim.xyz/T/#u
>> > > > case HCI_EV_CONN_COMPLETE:
>> > > > case HCI_EV_LE_CONN_COMPLETE:
>> > > > --
>> > > > 2.54.0
>> > > >
>> >
>> > There is an else if branch after it:
>> >
>> > if (conn->state == BT_CONNECT && hdev->sent_cmd) {
>> > switch (hci_skb_event(hdev->sent_cmd)) {
>> > case HCI_EV_CONN_COMPLETE:
>> > case HCI_EV_LE_CONN_COMPLETE:
>> > case HCI_EV_LE_ENHANCED_CONN_COMPLETE:
>> > case HCI_EVT_LE_CIS_ESTABLISHED:
>> > hci_cmd_sync_cancel(hdev, ECANCELED);
>> > break;
>> > }
>> > /* Cancel connect attempt if still queued/pending */
>> > } else if (!hci_cancel_connect_sync(hdev, conn)) {
>> > return 0;
>> > }
>> >
>> > I don't think replacing it is a wise choice as else if branch might be escaped accidentally.
>>
>> Perhaps we should change it. Maybe `hci_conn` could set a bit if it is
>> pending or just scheduled and it would probably be cleaner if
>> hci_cancel_connect_sync handles this internally.
>>
>> > e.g. status != pending can go to if branch and cancel in else if branch can never be executed.
>> >
>> > >
>> > >
>> > > --
>> > > Luiz Augusto von Dentz
>> >
>> > BTW, could you please check my explanation for another patch as well?
>> > https://lore.kernel.org/linux-bluetooth/20260603150835.3539963-1-oss@fourdim.xyz/T/#m0702d8586e0fb10775f4bd52998bf42e09b85af7
>> >
>> > Thank you.
>> >
>> > Best,
>> > Siwei
>>
>>
>
> --
> Pauli Virtanen
Best,
Siwei
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Pauli Virtanen @ 2026-06-10 15:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Siwei Zhang; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZKt14=Q_4RPpnZRBsnTZaOmBG3fvDHyB21+0_ndNXb5aw@mail.gmail.com>
Hi,
ke, 2026-06-10 kello 10:02 -0400, Luiz Augusto von Dentz kirjoitti:
> Hi Siwei,
>
> On Wed, Jun 10, 2026 at 9:52 AM Siwei Zhang <oss@fourdim.xyz> wrote:
> >
> > Hi Luiz,
> >
> > On Wed, Jun 10, 2026, at 9:14 AM, Luiz Augusto von Dentz wrote:
> > > Hi Siwei,
> > >
> > > On Wed, Jun 10, 2026 at 9:07 AM Siwei Zhang <oss@fourdim.xyz> wrote:
> > > >
> > > > hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
> > > > is pending, but hdev->sent_cmd can be NULL while req_status is still
> > > > HCI_REQ_PEND
> > >
> > > Can it really be NULL? If it can then I don't think we are handling
> > > HCI_REQ_PEND well and perhaps should instead just check hdev->sent_cmd
> > > directly instead of bothering with hdev->req_status.
> > >
> >
> > This is the crash stack.
> >
> > Title: general protection fault in hci_abort_conn
> > Type: general protection fault
> > Function: hci_abort_conn
> > Signature: f64ebf7af5cee01a
> > Time: 2026-06-01-12:48:57
> > ---
> > [ 1266.952280] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> > [ 1266.954486] KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> > [ 1266.955864] CPU: 0 UID: 0 PID: 384 Comm: kworker/u9:1 Tainted: G W 7.0.8-g8de79710cf39 #4 PREEMPT(lazy)
> > [ 1266.957695] Tainted: [W]=WARN
> > [ 1266.958535] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> > [ 1266.960480] Workqueue: hci0 hci_rx_work
> > [ 1266.961483] RIP: 0010:hci_abort_conn+0x179/0x2d0
> > [ 1266.962296] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
> > [ 1266.965380] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
> > [ 1266.966267] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
> > [ 1266.967770] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
> > [ 1266.969054] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
> > [ 1266.970874] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
> > [ 1266.972036] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
> > [ 1266.973213] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
> > [ 1266.974917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 1266.975867] CR2: 00007f51ba4e2020 CR3: 000000010fea7000 CR4: 00000000000006f0
> > [ 1266.977409] Call Trace:
> > [ 1266.977895] <TASK>
> > [ 1266.978676] hci_disconnect+0xe8/0x250 net/bluetooth/hci_conn.c:197
> > [ 1266.979781] ? lock_release+0xf8/0x370 kernel/locking/lockdep.c:5889
> > [ 1266.980541] ? __pfx_hci_disconnect+0x10/0x10 net/bluetooth/hci_conn.c:179
> > [ 1266.981926] ? hci_conn_hash_lookup_ba+0x29e/0x2c0 include/net/bluetooth/hci_core.h:1259
> > [ 1266.982879] ? __crypto_memneq+0x47/0x490 lib/crypto/memneq.c:169
> > [ 1266.983884] hci_link_key_notify_evt+0x21d/0xa50 net/bluetooth/hci_event.c:4750
> > [ 1266.984987] ? __pfx___mutex_unlock_slowpath+0x10/0x10 kernel/locking/mutex.c:932
> > [ 1266.985918] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
> > [ 1266.986769] ? skb_pull_data+0x100/0x1b0 net/core/skbuff.c:2710
> > [ 1266.987754] hci_event_packet+0x65e/0xd50
> > [ 1266.988429] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
> > [ 1266.989277] ? __pfx_hci_event_packet+0x10/0x10 net/bluetooth/hci_event.c:7803
> > [ 1266.990051] ? lockdep_hardirqs_on_prepare+0x168/0x230 kernel/locking/lockdep.c:4410
> > [ 1266.991088] ? hci_send_to_monitor+0xdd/0x510
> > [ 1266.991977] hci_rx_work+0x3d1/0x8d0 net/bluetooth/hci_core.c:4078
> > [ 1266.993050] ? process_scheduled_works+0xa01/0x1760 kernel/workqueue.c:3371
> > [ 1266.994019] process_scheduled_works+0xac1/0x1760 kernel/workqueue.c:3371
> > [ 1266.995274] ? trace_sched_exit_tp+0x35/0x130 include/trace/events/sched.h:886
> > [ 1266.996155] ? __pfx_process_scheduled_works+0x10/0x10 kernel/workqueue.c:3361
> > [ 1266.997132] ? do_raw_spin_lock+0x126/0x270 kernel/locking/spinlock_debug.c:116
> > [ 1266.997955] ? assign_work+0x333/0x4d0
> > [ 1266.998706] worker_thread+0xa22/0xf80 kernel/workqueue.c:3453
> > [ 1266.999792] ? __kthread_parkme+0x1a5/0x200
> > [ 1267.000591] kthread+0x38b/0x480 kernel/kthread.c:438
> > [ 1267.001680] ? __pfx_worker_thread+0x10/0x10 kernel/workqueue.c:3398
> > [ 1267.002499] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
> > [ 1267.003154] ret_from_fork+0x436/0x950 arch/x86/kernel/process.c:164
> > [ 1267.003797] ? __pfx_ret_from_fork+0x10/0x10 arch/x86/kernel/process.c:153
> > [ 1267.004501] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
> > [ 1267.005137] ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:258
> > [ 1267.005855] </TASK>
> > [ 1267.006918] Modules linked in:
> > [ 1267.008266] ---[ end trace 0000000000000000 ]---
> > [ 1267.010119] RIP: 0010:hci_abort_conn+0x179/0x2d0
> > [ 1267.011723] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
> > [ 1267.015717] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
> > [ 1267.016793] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
> > [ 1267.018342] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
> > [ 1267.019857] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
> > [ 1267.021481] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
> > [ 1267.022973] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
> > [ 1267.024217] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
> > [ 1267.025954] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >
> > > > , leading to a NULL pointer dereference and a general
> > > > protection fault from the hci_rx_work() receive path.
> > > >
> > > > Check hdev->sent_cmd before dereferencing it.
> > > >
> > > > Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> > > > ---
> > > > net/bluetooth/hci_conn.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > > > index 54eabaa46960..43fdacb2c9b2 100644
> > > > --- a/net/bluetooth/hci_conn.c
> > > > +++ b/net/bluetooth/hci_conn.c
> > > > @@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
> > > > * hci_connect_le serializes the connection attempts so only one
> > > > * connection can be in BT_CONNECT at time.
> > > > */
> > > > - if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
> > > > + if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
> > > > + hdev->sent_cmd) {
> > > > switch (hci_skb_event(hdev->sent_cmd)) {
The hdev->sent_cmd access here looks unsafe vs synchronization:
* hdev->sent_cmd pointer is modified (only) from hci_cmd_work() which
runs in hdev->workqueue.
* No lock is held, only the ordered hdev->workqueue synchronizes
* The skb pointed to is also freed from hdev->workqueue.
* Even if valid pointer to it is obtained, the skb may be freed under
us here
hci_abort_conn() is called from places like smp->security_timer ->
hci_disconnect() which run in kernel default workqueues -> potential
UAF here.
MGMT unpair_device_sync() appears to call it from hdev->req_workqueue,
which is then the same.
Taking hdev_lock doesn't help here, as it's only synchronized by the
workqueue.
The hdev->sent_cmd probably needs some new locking primitive, not sure
hdev->lock and hdev->req_lock can be used here as not sure what locking
contexts this is called from.
> > > > case HCI_EV_CONN_COMPLETE:
> > > > case HCI_EV_LE_CONN_COMPLETE:
> > > > --
> > > > 2.54.0
> > > >
> >
> > There is an else if branch after it:
> >
> > if (conn->state == BT_CONNECT && hdev->sent_cmd) {
> > switch (hci_skb_event(hdev->sent_cmd)) {
> > case HCI_EV_CONN_COMPLETE:
> > case HCI_EV_LE_CONN_COMPLETE:
> > case HCI_EV_LE_ENHANCED_CONN_COMPLETE:
> > case HCI_EVT_LE_CIS_ESTABLISHED:
> > hci_cmd_sync_cancel(hdev, ECANCELED);
> > break;
> > }
> > /* Cancel connect attempt if still queued/pending */
> > } else if (!hci_cancel_connect_sync(hdev, conn)) {
> > return 0;
> > }
> >
> > I don't think replacing it is a wise choice as else if branch might be escaped accidentally.
>
> Perhaps we should change it. Maybe `hci_conn` could set a bit if it is
> pending or just scheduled and it would probably be cleaner if
> hci_cancel_connect_sync handles this internally.
>
> > e.g. status != pending can go to if branch and cancel in else if branch can never be executed.
> >
> > >
> > >
> > > --
> > > Luiz Augusto von Dentz
> >
> > BTW, could you please check my explanation for another patch as well?
> > https://lore.kernel.org/linux-bluetooth/20260603150835.3539963-1-oss@fourdim.xyz/T/#m0702d8586e0fb10775f4bd52998bf42e09b85af7
> >
> > Thank you.
> >
> > Best,
> > Siwei
>
>
--
Pauli Virtanen
^ permalink raw reply
* [PATCH v2] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Siwei Zhang @ 2026-06-10 15:06 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Siwei Zhang
hci_abort_conn() read hci_skb_event(hdev->sent_cmd) when a connection
was pending, but hdev->sent_cmd can be NULL while req_status is still
HCI_REQ_PEND, leading to a NULL pointer dereference and a general
protection fault from the hci_rx_work() receive path.
Instead of inspecting hdev->sent_cmd, track the in-flight create
connection command with a new per-connection HCI_CONN_CREATE_CONN flag
and route all cancellation through hci_cancel_connect_sync(), which
dequeues the command if still queued, or cancels the pending request if
this connection owns the in-flight create command. CIS uses the same
path via the existing HCI_CONN_CREATE_CIS flag.
Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_conn.c | 21 ++----------
net/bluetooth/hci_sync.c | 58 +++++++++++++++++++++++++-------
3 files changed, 50 insertions(+), 30 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index aa600fbf9a53..c90ca6173680 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -988,6 +988,7 @@ enum {
HCI_CONN_AUTH_FAILURE,
HCI_CONN_PER_ADV,
HCI_CONN_BIG_CREATED,
+ HCI_CONN_CREATE_CONN,
HCI_CONN_CREATE_CIS,
HCI_CONN_CREATE_BIG_SYNC,
HCI_CONN_BIG_SYNC,
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 54eabaa46960..eba4a548bef5 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -3181,26 +3181,11 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
conn->abort_reason = reason;
- /* If the connection is pending check the command opcode since that
- * might be blocking on hci_cmd_sync_work while waiting its respective
- * event so we need to hci_cmd_sync_cancel to cancel it.
- *
- * hci_connect_le serializes the connection attempts so only one
- * connection can be in BT_CONNECT at time.
+ /* Cancel the connect attempt. A return of 0 means the create command
+ * was still queued and got dequeued, so there is nothing to disconnect.
*/
- if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
- switch (hci_skb_event(hdev->sent_cmd)) {
- case HCI_EV_CONN_COMPLETE:
- case HCI_EV_LE_CONN_COMPLETE:
- case HCI_EV_LE_ENHANCED_CONN_COMPLETE:
- case HCI_EVT_LE_CIS_ESTABLISHED:
- hci_cmd_sync_cancel(hdev, ECANCELED);
- break;
- }
- /* Cancel connect attempt if still queued/pending */
- } else if (!hci_cancel_connect_sync(hdev, conn)) {
+ if (!hci_cancel_connect_sync(hdev, conn))
return 0;
- }
/* Run immediately if on cmd_sync_work since this may be called
* as a result to MGMT_OP_DISCONNECT/MGMT_OP_UNPAIR which does
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index df23245d6ccd..08917b8167de 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -6668,6 +6668,12 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
&own_addr_type);
if (err)
goto done;
+
+ /* Mark create connection in flight so hci_cancel_connect_sync() can
+ * cancel it while blocking on the connection complete event.
+ */
+ set_bit(HCI_CONN_CREATE_CONN, &conn->flags);
+
/* Send command LE Extended Create Connection if supported */
if (use_ext_conn(hdev)) {
err = hci_le_ext_create_conn_sync(hdev, conn, own_addr_type);
@@ -6703,6 +6709,8 @@ static int hci_le_create_conn_sync(struct hci_dev *hdev, void *data)
conn->conn_timeout, NULL);
done:
+ clear_bit(HCI_CONN_CREATE_CONN, &conn->flags);
+
if (err == -ETIMEDOUT)
hci_le_connect_cancel_sync(hdev, conn, 0x00);
@@ -6982,10 +6990,19 @@ static int hci_acl_create_conn_sync(struct hci_dev *hdev, void *data)
else
cp.role_switch = 0x00;
- return __hci_cmd_sync_status_sk(hdev, HCI_OP_CREATE_CONN,
- sizeof(cp), &cp,
- HCI_EV_CONN_COMPLETE,
- conn->conn_timeout, NULL);
+ /* Mark create connection in flight so hci_cancel_connect_sync() can
+ * cancel it while blocking on the connection complete event.
+ */
+ set_bit(HCI_CONN_CREATE_CONN, &conn->flags);
+
+ err = __hci_cmd_sync_status_sk(hdev, HCI_OP_CREATE_CONN,
+ sizeof(cp), &cp,
+ HCI_EV_CONN_COMPLETE,
+ conn->conn_timeout, NULL);
+
+ clear_bit(HCI_CONN_CREATE_CONN, &conn->flags);
+
+ return err;
}
int hci_connect_acl_sync(struct hci_dev *hdev, struct hci_conn *conn)
@@ -7039,20 +7056,37 @@ int hci_connect_le_sync(struct hci_dev *hdev, struct hci_conn *conn)
int hci_cancel_connect_sync(struct hci_dev *hdev, struct hci_conn *conn)
{
- if (conn->state != BT_OPEN)
- return -EINVAL;
+ hci_cmd_sync_work_func_t func = NULL;
+ hci_cmd_sync_work_destroy_t destroy = NULL;
+ int create_flag = -1;
switch (conn->type) {
case ACL_LINK:
- return !hci_cmd_sync_dequeue_once(hdev,
- hci_acl_create_conn_sync,
- conn, NULL);
+ func = hci_acl_create_conn_sync;
+ create_flag = HCI_CONN_CREATE_CONN;
+ break;
case LE_LINK:
- return !hci_cmd_sync_dequeue_once(hdev, hci_le_create_conn_sync,
- conn, create_le_conn_complete);
+ func = hci_le_create_conn_sync;
+ destroy = create_le_conn_complete;
+ create_flag = HCI_CONN_CREATE_CONN;
+ break;
+ case CIS_LINK:
+ /* LE Create CIS is shared by the whole CIG and cannot be
+ * dequeued per-connection; only cancel it in-flight below.
+ */
+ create_flag = HCI_CONN_CREATE_CIS;
+ break;
+ default:
+ return -ENOENT;
}
- return -ENOENT;
+ if (func && hci_cmd_sync_dequeue_once(hdev, func, conn, destroy))
+ return 0;
+
+ if (create_flag >= 0 && test_bit(create_flag, &conn->flags))
+ hci_cmd_sync_cancel(hdev, ECANCELED);
+
+ return -EBUSY;
}
int hci_le_conn_update_sync(struct hci_dev *hdev, struct hci_conn *conn,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Luiz Augusto von Dentz @ 2026-06-10 14:52 UTC (permalink / raw)
To: Jordan Walters; +Cc: linux-bluetooth, linux-kernel
In-Reply-To: <20260603075134.246832-1-jaggyaur@gmail.com>
Hi Jordan,
On Wed, Jun 3, 2026 at 4:09 AM Jordan Walters <jaggyaur@gmail.com> wrote:
>
> The hci_unregister_dev() function fails to safely cancel the cmd_timer
> and ncmd_timer before freeing the hci_dev structure. If an asynchronous
> event or timeout occurs during device teardown, the timer callbacks
> may execute after the device has been freed, leading to a KASAN
> slab-use-after-free panic.
>
> This patch adds cancel_delayed_work_sync() calls at the end of
> hci_unregister_dev() after all teardown procedures have completed.
> This ensures the timers are fully flushed before the struct is freed,
> preventing any use-after-free conditions.
>
> Signed-off-by: Jordan Walters <jaggyaur@gmail.com>
> ---
> net/bluetooth/hci_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 28d7929dc59..3db1b3738b5 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2698,6 +2698,9 @@ void hci_unregister_dev(struct hci_dev *hdev)
> rfkill_unregister(hdev->rfkill);
> rfkill_destroy(hdev->rfkill);
> }
>
> device_del(&hdev->dev);
> +
> + cancel_delayed_work_sync(&hdev->cmd_timer);
> + cancel_delayed_work_sync(&hdev->ncmd_timer);
> +
> /* Actual cleanup is deferred until hci_release_dev(). */
> hci_dev_put(hdev);
> }
I'm not sure what's happening, but I cannot apply this change with
`git am`. Also, why did you revert to using `cancel` instead of
`disable`?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref
From: patchwork-bot+bluetooth @ 2026-06-10 14:40 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260609193222.192456-1-luiz.dentz@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 9 Jun 2026 15:32:22 -0400 you wrote:
> From: Marco Elver <elver@google.com>
>
> l2cap_chan_timeout() runs asynchronously and accesses chan->conn. If
> the connection is torn down while the timer is running or pending,
> chan->conn can be freed, leading to a use-after-free when the timer
> worker attempts to lock conn->lock:
>
> [...]
Here is the summary with links:
- [v3] Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref
https://git.kernel.org/bluetooth/bluetooth-next/c/06528e2f5fc9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Luiz Augusto von Dentz @ 2026-06-10 14:02 UTC (permalink / raw)
To: Siwei Zhang; +Cc: linux-bluetooth
In-Reply-To: <88931814-4915-40a5-8e21-66ddbdb2a530@app.fastmail.com>
Hi Siwei,
On Wed, Jun 10, 2026 at 9:52 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> Hi Luiz,
>
> On Wed, Jun 10, 2026, at 9:14 AM, Luiz Augusto von Dentz wrote:
> > Hi Siwei,
> >
> > On Wed, Jun 10, 2026 at 9:07 AM Siwei Zhang <oss@fourdim.xyz> wrote:
> >>
> >> hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
> >> is pending, but hdev->sent_cmd can be NULL while req_status is still
> >> HCI_REQ_PEND
> >
> > Can it really be NULL? If it can then I don't think we are handling
> > HCI_REQ_PEND well and perhaps should instead just check hdev->sent_cmd
> > directly instead of bothering with hdev->req_status.
> >
>
> This is the crash stack.
>
> Title: general protection fault in hci_abort_conn
> Type: general protection fault
> Function: hci_abort_conn
> Signature: f64ebf7af5cee01a
> Time: 2026-06-01-12:48:57
> ---
> [ 1266.952280] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> [ 1266.954486] KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> [ 1266.955864] CPU: 0 UID: 0 PID: 384 Comm: kworker/u9:1 Tainted: G W 7.0.8-g8de79710cf39 #4 PREEMPT(lazy)
> [ 1266.957695] Tainted: [W]=WARN
> [ 1266.958535] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> [ 1266.960480] Workqueue: hci0 hci_rx_work
> [ 1266.961483] RIP: 0010:hci_abort_conn+0x179/0x2d0
> [ 1266.962296] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
> [ 1266.965380] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
> [ 1266.966267] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
> [ 1266.967770] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
> [ 1266.969054] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
> [ 1266.970874] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
> [ 1266.972036] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
> [ 1266.973213] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
> [ 1266.974917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1266.975867] CR2: 00007f51ba4e2020 CR3: 000000010fea7000 CR4: 00000000000006f0
> [ 1266.977409] Call Trace:
> [ 1266.977895] <TASK>
> [ 1266.978676] hci_disconnect+0xe8/0x250 net/bluetooth/hci_conn.c:197
> [ 1266.979781] ? lock_release+0xf8/0x370 kernel/locking/lockdep.c:5889
> [ 1266.980541] ? __pfx_hci_disconnect+0x10/0x10 net/bluetooth/hci_conn.c:179
> [ 1266.981926] ? hci_conn_hash_lookup_ba+0x29e/0x2c0 include/net/bluetooth/hci_core.h:1259
> [ 1266.982879] ? __crypto_memneq+0x47/0x490 lib/crypto/memneq.c:169
> [ 1266.983884] hci_link_key_notify_evt+0x21d/0xa50 net/bluetooth/hci_event.c:4750
> [ 1266.984987] ? __pfx___mutex_unlock_slowpath+0x10/0x10 kernel/locking/mutex.c:932
> [ 1266.985918] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
> [ 1266.986769] ? skb_pull_data+0x100/0x1b0 net/core/skbuff.c:2710
> [ 1266.987754] hci_event_packet+0x65e/0xd50
> [ 1266.988429] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
> [ 1266.989277] ? __pfx_hci_event_packet+0x10/0x10 net/bluetooth/hci_event.c:7803
> [ 1266.990051] ? lockdep_hardirqs_on_prepare+0x168/0x230 kernel/locking/lockdep.c:4410
> [ 1266.991088] ? hci_send_to_monitor+0xdd/0x510
> [ 1266.991977] hci_rx_work+0x3d1/0x8d0 net/bluetooth/hci_core.c:4078
> [ 1266.993050] ? process_scheduled_works+0xa01/0x1760 kernel/workqueue.c:3371
> [ 1266.994019] process_scheduled_works+0xac1/0x1760 kernel/workqueue.c:3371
> [ 1266.995274] ? trace_sched_exit_tp+0x35/0x130 include/trace/events/sched.h:886
> [ 1266.996155] ? __pfx_process_scheduled_works+0x10/0x10 kernel/workqueue.c:3361
> [ 1266.997132] ? do_raw_spin_lock+0x126/0x270 kernel/locking/spinlock_debug.c:116
> [ 1266.997955] ? assign_work+0x333/0x4d0
> [ 1266.998706] worker_thread+0xa22/0xf80 kernel/workqueue.c:3453
> [ 1266.999792] ? __kthread_parkme+0x1a5/0x200
> [ 1267.000591] kthread+0x38b/0x480 kernel/kthread.c:438
> [ 1267.001680] ? __pfx_worker_thread+0x10/0x10 kernel/workqueue.c:3398
> [ 1267.002499] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
> [ 1267.003154] ret_from_fork+0x436/0x950 arch/x86/kernel/process.c:164
> [ 1267.003797] ? __pfx_ret_from_fork+0x10/0x10 arch/x86/kernel/process.c:153
> [ 1267.004501] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
> [ 1267.005137] ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:258
> [ 1267.005855] </TASK>
> [ 1267.006918] Modules linked in:
> [ 1267.008266] ---[ end trace 0000000000000000 ]---
> [ 1267.010119] RIP: 0010:hci_abort_conn+0x179/0x2d0
> [ 1267.011723] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
> [ 1267.015717] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
> [ 1267.016793] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
> [ 1267.018342] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
> [ 1267.019857] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
> [ 1267.021481] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
> [ 1267.022973] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
> [ 1267.024217] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
> [ 1267.025954] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>
> >> , leading to a NULL pointer dereference and a general
> >> protection fault from the hci_rx_work() receive path.
> >>
> >> Check hdev->sent_cmd before dereferencing it.
> >>
> >> Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> >> ---
> >> net/bluetooth/hci_conn.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> >> index 54eabaa46960..43fdacb2c9b2 100644
> >> --- a/net/bluetooth/hci_conn.c
> >> +++ b/net/bluetooth/hci_conn.c
> >> @@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
> >> * hci_connect_le serializes the connection attempts so only one
> >> * connection can be in BT_CONNECT at time.
> >> */
> >> - if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
> >> + if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
> >> + hdev->sent_cmd) {
> >> switch (hci_skb_event(hdev->sent_cmd)) {
> >> case HCI_EV_CONN_COMPLETE:
> >> case HCI_EV_LE_CONN_COMPLETE:
> >> --
> >> 2.54.0
> >>
>
> There is an else if branch after it:
>
> if (conn->state == BT_CONNECT && hdev->sent_cmd) {
> switch (hci_skb_event(hdev->sent_cmd)) {
> case HCI_EV_CONN_COMPLETE:
> case HCI_EV_LE_CONN_COMPLETE:
> case HCI_EV_LE_ENHANCED_CONN_COMPLETE:
> case HCI_EVT_LE_CIS_ESTABLISHED:
> hci_cmd_sync_cancel(hdev, ECANCELED);
> break;
> }
> /* Cancel connect attempt if still queued/pending */
> } else if (!hci_cancel_connect_sync(hdev, conn)) {
> return 0;
> }
>
> I don't think replacing it is a wise choice as else if branch might be escaped accidentally.
Perhaps we should change it. Maybe `hci_conn` could set a bit if it is
pending or just scheduled and it would probably be cleaner if
hci_cancel_connect_sync handles this internally.
> e.g. status != pending can go to if branch and cancel in else if branch can never be executed.
>
> >
> >
> > --
> > Luiz Augusto von Dentz
>
> BTW, could you please check my explanation for another patch as well?
> https://lore.kernel.org/linux-bluetooth/20260603150835.3539963-1-oss@fourdim.xyz/T/#m0702d8586e0fb10775f4bd52998bf42e09b85af7
>
> Thank you.
>
> Best,
> Siwei
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Siwei Zhang @ 2026-06-10 13:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZKCciLjShDCi0NR53WA9KvQjMo_sMyEwtvWFCsJ0MSZDw@mail.gmail.com>
Hi Luiz,
On Wed, Jun 10, 2026, at 9:14 AM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, Jun 10, 2026 at 9:07 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
>> is pending, but hdev->sent_cmd can be NULL while req_status is still
>> HCI_REQ_PEND
>
> Can it really be NULL? If it can then I don't think we are handling
> HCI_REQ_PEND well and perhaps should instead just check hdev->sent_cmd
> directly instead of bothering with hdev->req_status.
>
This is the crash stack.
Title: general protection fault in hci_abort_conn
Type: general protection fault
Function: hci_abort_conn
Signature: f64ebf7af5cee01a
Time: 2026-06-01-12:48:57
---
[ 1266.952280] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
[ 1266.954486] KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
[ 1266.955864] CPU: 0 UID: 0 PID: 384 Comm: kworker/u9:1 Tainted: G W 7.0.8-g8de79710cf39 #4 PREEMPT(lazy)
[ 1266.957695] Tainted: [W]=WARN
[ 1266.958535] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 1266.960480] Workqueue: hci0 hci_rx_work
[ 1266.961483] RIP: 0010:hci_abort_conn+0x179/0x2d0
[ 1266.962296] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
[ 1266.965380] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
[ 1266.966267] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
[ 1266.967770] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
[ 1266.969054] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[ 1266.970874] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
[ 1266.972036] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
[ 1266.973213] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
[ 1266.974917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1266.975867] CR2: 00007f51ba4e2020 CR3: 000000010fea7000 CR4: 00000000000006f0
[ 1266.977409] Call Trace:
[ 1266.977895] <TASK>
[ 1266.978676] hci_disconnect+0xe8/0x250 net/bluetooth/hci_conn.c:197
[ 1266.979781] ? lock_release+0xf8/0x370 kernel/locking/lockdep.c:5889
[ 1266.980541] ? __pfx_hci_disconnect+0x10/0x10 net/bluetooth/hci_conn.c:179
[ 1266.981926] ? hci_conn_hash_lookup_ba+0x29e/0x2c0 include/net/bluetooth/hci_core.h:1259
[ 1266.982879] ? __crypto_memneq+0x47/0x490 lib/crypto/memneq.c:169
[ 1266.983884] hci_link_key_notify_evt+0x21d/0xa50 net/bluetooth/hci_event.c:4750
[ 1266.984987] ? __pfx___mutex_unlock_slowpath+0x10/0x10 kernel/locking/mutex.c:932
[ 1266.985918] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
[ 1266.986769] ? skb_pull_data+0x100/0x1b0 net/core/skbuff.c:2710
[ 1266.987754] hci_event_packet+0x65e/0xd50
[ 1266.988429] ? __pfx_hci_link_key_notify_evt+0x10/0x10 net/bluetooth/hci_event.c:4730
[ 1266.989277] ? __pfx_hci_event_packet+0x10/0x10 net/bluetooth/hci_event.c:7803
[ 1266.990051] ? lockdep_hardirqs_on_prepare+0x168/0x230 kernel/locking/lockdep.c:4410
[ 1266.991088] ? hci_send_to_monitor+0xdd/0x510
[ 1266.991977] hci_rx_work+0x3d1/0x8d0 net/bluetooth/hci_core.c:4078
[ 1266.993050] ? process_scheduled_works+0xa01/0x1760 kernel/workqueue.c:3371
[ 1266.994019] process_scheduled_works+0xac1/0x1760 kernel/workqueue.c:3371
[ 1266.995274] ? trace_sched_exit_tp+0x35/0x130 include/trace/events/sched.h:886
[ 1266.996155] ? __pfx_process_scheduled_works+0x10/0x10 kernel/workqueue.c:3361
[ 1266.997132] ? do_raw_spin_lock+0x126/0x270 kernel/locking/spinlock_debug.c:116
[ 1266.997955] ? assign_work+0x333/0x4d0
[ 1266.998706] worker_thread+0xa22/0xf80 kernel/workqueue.c:3453
[ 1266.999792] ? __kthread_parkme+0x1a5/0x200
[ 1267.000591] kthread+0x38b/0x480 kernel/kthread.c:438
[ 1267.001680] ? __pfx_worker_thread+0x10/0x10 kernel/workqueue.c:3398
[ 1267.002499] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
[ 1267.003154] ret_from_fork+0x436/0x950 arch/x86/kernel/process.c:164
[ 1267.003797] ? __pfx_ret_from_fork+0x10/0x10 arch/x86/kernel/process.c:153
[ 1267.004501] ? __pfx_kthread+0x10/0x10 kernel/kthread.c:381
[ 1267.005137] ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:258
[ 1267.005855] </TASK>
[ 1267.006918] Modules linked in:
[ 1267.008266] ---[ end trace 0000000000000000 ]---
[ 1267.010119] RIP: 0010:hci_abort_conn+0x179/0x2d0
[ 1267.011723] Code: 8d be 48 0e 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 05 a8 9b fc 4d 8b 3f 49 83 c7 3b 4c 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 29 01 00 00 45 0f b6 3f 4c 89 ff 48 c7
[ 1267.015717] RSP: 0018:ffffc9000a277760 EFLAGS: 00010212
[ 1267.016793] RAX: 0000000000000007 RBX: ffff888114d4c000 RCX: 0000000000000000
[ 1267.018342] RDX: ffff8881110f3600 RSI: 0000000000000001 RDI: 0000000000000001
[ 1267.019857] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[ 1267.021481] R10: 0000000000000000 R11: ffffffff85464c1b R12: 0000000000000005
[ 1267.022973] R13: dffffc0000000000 R14: ffff88810f810000 R15: 000000000000003b
[ 1267.024217] FS: 0000000000000000(0000) GS:ffff888190689000(0000) knlGS:0000000000000000
[ 1267.025954] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> , leading to a NULL pointer dereference and a general
>> protection fault from the hci_rx_work() receive path.
>>
>> Check hdev->sent_cmd before dereferencing it.
>>
>> Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
>> ---
>> net/bluetooth/hci_conn.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 54eabaa46960..43fdacb2c9b2 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
>> * hci_connect_le serializes the connection attempts so only one
>> * connection can be in BT_CONNECT at time.
>> */
>> - if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
>> + if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
>> + hdev->sent_cmd) {
>> switch (hci_skb_event(hdev->sent_cmd)) {
>> case HCI_EV_CONN_COMPLETE:
>> case HCI_EV_LE_CONN_COMPLETE:
>> --
>> 2.54.0
>>
There is an else if branch after it:
if (conn->state == BT_CONNECT && hdev->sent_cmd) {
switch (hci_skb_event(hdev->sent_cmd)) {
case HCI_EV_CONN_COMPLETE:
case HCI_EV_LE_CONN_COMPLETE:
case HCI_EV_LE_ENHANCED_CONN_COMPLETE:
case HCI_EVT_LE_CIS_ESTABLISHED:
hci_cmd_sync_cancel(hdev, ECANCELED);
break;
}
/* Cancel connect attempt if still queued/pending */
} else if (!hci_cancel_connect_sync(hdev, conn)) {
return 0;
}
I don't think replacing it is a wise choice as else if branch might be escaped accidentally.
e.g. status != pending can go to if branch and cancel in else if branch can never be executed.
>
>
> --
> Luiz Augusto von Dentz
BTW, could you please check my explanation for another patch as well?
https://lore.kernel.org/linux-bluetooth/20260603150835.3539963-1-oss@fourdim.xyz/T/#m0702d8586e0fb10775f4bd52998bf42e09b85af7
Thank you.
Best,
Siwei
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-10 13:49 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1092705
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Luiz Augusto von Dentz @ 2026-06-10 13:14 UTC (permalink / raw)
To: Siwei Zhang; +Cc: linux-bluetooth
In-Reply-To: <20260610130648.1091326-1-oss@fourdim.xyz>
Hi Siwei,
On Wed, Jun 10, 2026 at 9:07 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
> is pending, but hdev->sent_cmd can be NULL while req_status is still
> HCI_REQ_PEND
Can it really be NULL? If it can then I don't think we are handling
HCI_REQ_PEND well and perhaps should instead just check hdev->sent_cmd
directly instead of bothering with hdev->req_status.
, leading to a NULL pointer dereference and a general
> protection fault from the hci_rx_work() receive path.
>
> Check hdev->sent_cmd before dereferencing it.
>
> Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
> Cc: stable@vger.kernel.org
> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> ---
> net/bluetooth/hci_conn.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 54eabaa46960..43fdacb2c9b2 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
> * hci_connect_le serializes the connection attempts so only one
> * connection can be in BT_CONNECT at time.
> */
> - if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
> + if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
> + hdev->sent_cmd) {
> switch (hci_skb_event(hdev->sent_cmd)) {
> case HCI_EV_CONN_COMPLETE:
> case HCI_EV_LE_CONN_COMPLETE:
> --
> 2.54.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Transition ASE to QoS Configured on CIS loss
From: Luiz Augusto von Dentz @ 2026-06-10 13:10 UTC (permalink / raw)
To: Simon Mikuda; +Cc: Pauli Virtanen, linux-bluetooth
In-Reply-To: <ac997f34-8c43-4935-bc78-90fa5eef714b@streamunlimited.com>
Hi Simon,
On Wed, Jun 10, 2026 at 4:03 AM Simon Mikuda
<simon.mikuda@streamunlimited.com> wrote:
>
> this check is for ep (struct bt_bap_endpoint) that is used only for
> unicast. broadcasts use different state in struct bt_bap_stream, so it
> should be OK
>
> On 6/10/26 00:15, Pauli Virtanen wrote:
> > ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
> >> stream_io_disconnected() only handled the Releasing state, leaving
> >> Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
> >> unexpectedly. The ASE shall autonomously move to QoS Configured on loss
> >> of the CIS and notify the peer; add that transition.
> >>
> >> Fixes PTS test BAP/USR/SCC/BV-167-C
> >> ---
> >> src/shared/bap.c | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/src/shared/bap.c b/src/shared/bap.c
> >> index deb85b264..350ed53d9 100644
> >> --- a/src/shared/bap.c
> >> +++ b/src/shared/bap.c
> >> @@ -6779,6 +6779,14 @@ static bool stream_io_disconnected(struct io *io, void *user_data)
> >> if (stream->ep->state == BT_ASCS_ASE_STATE_RELEASING)
> >> stream_set_state(stream, BT_BAP_STREAM_STATE_CONFIG);
> >>
> >> + /* On loss of the CIS the ASE shall autonomously transition to QoS
> >> + * Configured and notify the peer.
> >> + */
> >> + if (stream->ep->state == BT_ASCS_ASE_STATE_STREAMING ||
> >> + stream->ep->state == BT_ASCS_ASE_STATE_ENABLING ||
> >> + stream->ep->state == BT_ASCS_ASE_STATE_DISABLING)
> >> + stream_set_state(stream, BT_BAP_STREAM_STATE_QOS);
> >> +
I think converting this to a switch statement might be better, as it
would allow us to handle all states, including releasing, within it.
It would be great to have test-bap cover these types of tests as well.
> >> bt_bap_stream_set_io(stream, -1);
> >> return false;
> >> }
> > iirc it may be also broadcast source here, does it do the right thing?
> >
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()
From: Siwei Zhang @ 2026-06-10 13:06 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Siwei Zhang
hci_abort_conn() reads hci_skb_event(hdev->sent_cmd) when a connection
is pending, but hdev->sent_cmd can be NULL while req_status is still
HCI_REQ_PEND, leading to a NULL pointer dereference and a general
protection fault from the hci_rx_work() receive path.
Check hdev->sent_cmd before dereferencing it.
Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections")
Cc: stable@vger.kernel.org
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
net/bluetooth/hci_conn.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 54eabaa46960..43fdacb2c9b2 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -3188,7 +3188,8 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
* hci_connect_le serializes the connection attempts so only one
* connection can be in BT_CONNECT at time.
*/
- if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
+ if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
+ hdev->sent_cmd) {
switch (hci_skb_event(hdev->sent_cmd)) {
case HCI_EV_CONN_COMPLETE:
case HCI_EV_LE_CONN_COMPLETE:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH BlueZ] shared/bap: Don't link ucast streams before CIS IDs are assigned
From: Luiz Augusto von Dentz @ 2026-06-10 13:06 UTC (permalink / raw)
To: Simon Mikuda; +Cc: Pauli Virtanen, linux-bluetooth
In-Reply-To: <fa0febe1-5866-4a3f-9f86-ae70e9d4b22d@streamunlimited.com>
Hi Simon,
On Wed, Jun 10, 2026 at 3:51 AM Simon Mikuda
<simon.mikuda@streamunlimited.com> wrote:
>
> I looked into it and 0 is valid ID (probably not used, but still valid).
>
> There is a ugly part in bluez though, when stream is allocated cig and
> cis in qos struct are 0 not 0xff:
>
> stream = new0(struct bt_bap_stream, 1); /* qos all-zero: cig/cis = 0 */
>
> and also in tests there are some struct comparisons that also use
> cig/cis == 0. Some parts check for 0xff (BT_ISO_QOS_CIG_UNSET,
> BT_ISO_QOS_CIS_UNSET)
We should probably initialize it with unset and then check if CIS/CIG
have been set upon linking.
> Maybe more clean fix would be to hook this up to state, so that when
> CIG/CIS is not at least configured it is rejected e.g.:
>
> if (stream->ep->state < BT_ASCS_ASE_STATE_QOS || link->ep->state <
> BT_ASCS_ASE_STATE_QOS)
> return -EINVAL;
>
> Also probably i should cleanup all structs (code and tests), so that cig
> and cis are initialized properly with 0xff. And then provide the fix?
>
> On 6/10/26 00:03, Pauli Virtanen wrote:
> > ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
> >> bap_ucast_io_link pairs streams whose CIG/CIS IDs match, but the IDs
> >> are unset in Codec Configured state, so a Sink and Source bound for
> >> different CISes get linked. The stray link later propagates a
> >> disconnect to the wrong ASE and breaks Receiver Start Ready.
> >>
> >> Skip linking until QoS Configured assigns the IDs.
> >>
> >> Fixes PTS test BAP/USR/STR/BV-362-C
> >> ---
> >> src/shared/bap.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/src/shared/bap.c b/src/shared/bap.c
> >> index deb85b264..98537de60 100644
> >> --- a/src/shared/bap.c
> >> +++ b/src/shared/bap.c
> >> @@ -2679,6 +2679,12 @@ static int bap_ucast_io_link(struct bt_bap_stream *stream,
> >> stream->ep->dir == link->ep->dir)
> >> return -EINVAL;
> >>
> >> + /* Don't link until QoS Configured assigns the CIS IDs; while unset
> >> + * the check above would pair unrelated streams.
> >> + */
> >> + if (!stream->qos.ucast.cis_id || !link->qos.ucast.cis_id)
> >> + return -EINVAL;
> > Zero is valid CIS ID?
> >
> >> +
> >> if (stream->client && !(stream->locked && link->locked))
> >> return -EINVAL;
> >>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] 6lowpan: fix NHC entry use-after-free on error path
From: Alexander Aring @ 2026-06-10 13:05 UTC (permalink / raw)
To: Yizhou Zhao
Cc: linux-bluetooth, Alexander Aring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-wpan, netdev,
linux-kernel, Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu,
stable
In-Reply-To: <20260609080054.4541-1-zhaoyz24@mails.tsinghua.edu.cn>
Hi,
On Tue, Jun 9, 2026 at 4:03 AM Yizhou Zhao
<zhaoyz24@mails.tsinghua.edu.cn> wrote:
>
> lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding
> lowpan_nhc_lock. If the descriptor has no uncompress callback, the error
> path drops the lock before printing nhc->name.
>
> lowpan_nhc_del() removes descriptors under the same lock and then relies
> on synchronize_net() before the owning module can be unloaded. That only
> waits for net RX RCU readers. lowpan_header_decompress() is also exported
> and can be reached from callers that are not necessarily covered by the net
> core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive
> path.
>
> This leaves a race where one task drops lowpan_nhc_lock in the error path,
> another task unregisters and frees the matching descriptor after
> synchronize_net() returns, and the first task then dereferences nhc->name
> for the warning.
>
> With the post-unlock window widened, KASAN reports:
>
> BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220
> Read of size 8
> lowpan_nhc_do_uncompression
> lowpan_header_decompress
>
> Fix this by printing the warning before dropping lowpan_nhc_lock, so the
> descriptor name is read while unregister is still excluded. The malformed
> packet is still rejected with -ENOTSUPP.
>
> Fixes: 92aa7c65d295 ("6lowpan: add generic nhc layer interface")
> Cc: stable@vger.kernel.org
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
looks good. Thanks.
Acked-by: Alexander Aring <aahringo@redhat.com>
- Alex
^ permalink raw reply
* Re: [PATCH v2 0/7] arm64: dts: qcom: enable WiFi/BT on SM8350 HDK
From: Konrad Dybcio @ 2026-06-10 11:56 UTC (permalink / raw)
To: Rob Herring, Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Qiang Yu, Jeff Johnson,
Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pci, linux-kernel,
linux-wireless, ath11k, devicetree, Bartosz Golaszewski,
linux-bluetooth, Bartosz Golaszewski
In-Reply-To: <20260608151835.GA2707238-robh@kernel.org>
On 6/8/26 5:18 PM, Rob Herring wrote:
> On Mon, Jun 08, 2026 at 09:59:18AM +0300, Dmitry Baryshkov wrote:
>> The SM8350 HDK has an onboard WCN6851 WiFi/BT chip, which for a long
>> time was not supported. Bring up different pieces required to enable
>> this SoC.
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Bumped num_vdevs to 4 to follow other similar devices (Jeff)
>> - Link to v1: https://patch.msgid.link/20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com
>>
>> ---
>> Dmitry Baryshkov (7):
>> PCI: qcom: fix parsing of PERST# in the legacy case
>> wifi: ath11k: enable support for WCN6851
>> regulator: dt-bindings: qcom,qca6390-pmu: document WCN6851
>> dt-bindings: bluetooth: qcom,wcn6855-bt: document WCN6851
>> arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
>> arm64: dts: qcom: sm8350: modernize PCIe entries
>> arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
>
> Before adding new devices, can you (Qcom) fix the all the existing DT
> warnings related to QCom WiFi/BT:
>
> 6 (qcom,wcn6855-bt): 'vddrfa1p7-supply' is a required property
> 6 (qcom,wcn6855-bt): Unevaluated properties are not allowed ('vddrfa1p8-supply' was unexpected)
> 2 (qcom,wcn6855-bt): 'vddwlmx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddwlcx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddbtcmx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddaon-supply' is a required property
> 2 (pci17cb,1103): 'vddwlmx-supply' is a required property
> 2 (pci17cb,1103): 'vddwlcx-supply' is a required property
> 2 (pci17cb,1103): 'vddrfacmn-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa1p8-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa1p2-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa0p8-supply' is a required property
> 2 (pci17cb,1103): 'vddpcie1p8-supply' is a required property
> 2 (pci17cb,1103): 'vddpcie0p9-supply' is a required property
> 2 (pci17cb,1103): 'vddaon-supply' is a required property
Most of them will be gone with
https://lore.kernel.org/linux-arm-msm/20260522-surface-sp9-5g-for-next-v2-8-dd9d477407f5@gmail.com/
a single dt generates 2 DTBs (one overlayed) that throw almost all of
these errors.. we should be able to tackle the rest that remain shortly
Konrad
^ permalink raw reply
* RE: [BlueZ,v2] adapter: Fix failed bonding attempt after LE link disconnection
From: bluez.test.bot @ 2026-06-10 11:02 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260610082054.3915366-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 825 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=1109089
---Test result---
Test Summary:
CheckPatch PASS 5.58 seconds
GitLint PASS 0.33 seconds
BuildEll PASS 21.00 seconds
BluezMake PASS 619.90 seconds
CheckSmatch PASS 325.95 seconds
bluezmakeextell PASS 166.15 seconds
IncrementalBuild PASS 605.73 seconds
ScanBuild PASS 948.54 seconds
https://github.com/bluez/bluez/pull/2213
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-10 10:16 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1107775
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] cc2e16: adapter: Fix failed bonding attempt after LE link ...
From: Šimon Mikuda @ 2026-06-10 10:16 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1109089
Home: https://github.com/bluez/bluez
Commit: cc2e16f0137dbc4f21b2f5078d2c28b63a886260
https://github.com/bluez/bluez/commit/cc2e16f0137dbc4f21b2f5078d2c28b63a886260
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: Fix failed bonding attempt after LE link disconnection
What happens when issue occurs:
- device is connected to both bearers BR/EDR and LE
- bonding is requested
- LE link disconnects
- pairing keys arrive
BlueZ would finish bonding request with error and mark device as
temporary. Then it would be disconnected+removed after default
temporary timeout (30 seconds).
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* RE: [v2] Bluetooth: qca: Add BT FW build version to kernel log
From: bluez.test.bot @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-bluetooth, xiuzhuo.shang
In-Reply-To: <20260610064232.2385866-1-xiuzhuo.shang@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 988 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=1109012
---Test result---
Test Summary:
CheckPatch PASS 0.53 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 0.20 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.56 seconds
CheckAllWarning PASS 29.70 seconds
CheckSparse PASS 27.92 seconds
BuildKernel32 PASS 26.02 seconds
TestRunnerSetup PASS 573.52 seconds
IncrementalBuild PASS 25.70 seconds
https://github.com/bluez/bluetooth-next/pull/301
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Sergey Senozhatsky @ 2026-06-10 8:51 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen
Cc: Sean Wang, Tomasz Figa, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Sergey Senozhatsky
In-Reply-To: <20260609121329.1262170-1-senozhatsky@chromium.org>
On (26/06/09 21:10), Sergey Senozhatsky wrote:
> Every once in a while we see a hung btmtksdio_flush() task:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> It all boils down to incorrect time_is_before_jiffies() usage in
> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> to be terminated if running for longer than 5*HZ. However the
> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> When the loop becomes infinite btmtksdio_txrx_work() loop never
> terminates and never releases the SDIO host.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
Please hold off this patch, this change alone might not be enough.
Let us look closer into it, we'll come back you.
^ permalink raw reply
* Re: "cleanup" variable attribute follow-up
From: Bastien Nocera @ 2026-06-10 8:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <6a284da8.7dd3efdf.a331b.6852@mx.google.com>
I have fixes for some of the warnings checkpatch threw:
https://github.com/hadess/bluez/commit/1f69ae6c89e6811f554087a35152b9e5b5f20e5c
Let me know if you want me to send them in a v2.
Cheers
On Tue, 2026-06-09 at 10:30 -0700, bluez.test.bot@gmail.com wrote:
> 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=1108
> 616
>
> ---Test result---
>
> Test Summary:
> CheckPatch FAIL 2.51 seconds
> GitLint PASS 1.73 seconds
> BuildEll PASS 16.19 seconds
> BluezMake PASS 498.81 seconds
> MakeCheck PASS 18.30 seconds
> MakeDistcheck PASS 189.35 seconds
> CheckValgrind PASS 217.95 seconds
> CheckSmatch WARNING 253.71 seconds
> bluezmakeextell PASS 131.42 seconds
> IncrementalBuild PASS 985.31 seconds
> ScanBuild PASS 733.50 seconds
>
> Details
> ##############################
> Test: CheckPatch - FAIL
> Desc: Run checkpatch.pl script
> Output:
> [BlueZ,1/6] shared/util: Fix warnings when cleaning up NULL pointers
> WARNING:LONG_LINE: line length of 94 exceeds 80 columns
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed.
> WARNING:SPACING: space prohibited between function name and open
> parenthesis '('
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxO)
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Bogus.
> ^
>
> ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed.
>
> /github/workspace/src/patch/14619750.patch total: 2 errors, 2
> warnings, 8 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
> mechanically convert to the typical style using --fix or --fix-
> inplace.
>
> /github/workspace/src/patch/14619750.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,4/6] main: Use _cleanup_() to simplify configuration parsing
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #90: FILE: src/main.c:265:
> + _cleanup_type_(GError) GError *err = NULL;
Those are all bogus, not sure why it's complaining there.
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #114: FILE: src/main.c:447:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #210: FILE: src/main.c:895:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #415: FILE: src/main.c:1214:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #507: FILE: src/main.c:1577:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> /github/workspace/src/patch/14619699.patch total: 5 errors, 0
> warnings, 420 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/14619699.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.
>
>
> ##############################
> Test: CheckSmatch - WARNING
> Desc: Run smatch tool with source
> Output:
> src/main.c: note: in included file (through src/device.h):
>
>
> https://github.com/bluez/bluez/pull/2201
>
> ---
> Regards,
> Linux Bluetooth
^ permalink raw reply
* RE: [v2] Bluetooth: SCO: Fix use-after-free on listening socket in sco_conn_ready()
From: bluez.test.bot @ 2026-06-10 8:33 UTC (permalink / raw)
To: linux-bluetooth, sanghyun.park.cnu
In-Reply-To: <20260610060824.552957-2-sanghyun.park.cnu@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: net/bluetooth/sco.c:410
error: net/bluetooth/sco.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
* [PATCH BlueZ v2] adapter: Fix failed bonding attempt after LE link disconnection
From: Simon Mikuda @ 2026-06-10 8:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <20260608111034.3684632-1-simon.mikuda@streamunlimited.com>
What happens when issue occurs:
- device is connected to both bearers BR/EDR and LE
- bonding is requested
- LE link disconnects
- pairing keys arrive
BlueZ would finish bonding request with error and mark device as
temporary. Then it would be disconnected+removed after default
temporary timeout (30 seconds).
---
src/adapter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index cc753fbd6..538f63e0a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -8622,7 +8622,9 @@ static void dev_disconnected(struct btd_adapter *adapter,
disconnect_notify(device, reason);
}
- bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
+ /* device could be still connected to different bearer */
+ if (!device || !btd_device_is_connected(device))
+ bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
MGMT_STATUS_DISCONNECTED);
}
--
2.43.0
^ permalink raw reply related
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