* Re: [PATCH] Bluetooth: sco: Fix a race condition in sco_sock_timeout()
From: Sungwoo Kim @ 2026-06-24 22:32 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Dave Tian, Luiz Augusto von Dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260624213304.1460149-2-iam@sung-woo.kim>
On Wed, Jun 24, 2026 at 5:36 PM Sungwoo Kim <iam@sung-woo.kim> wrote:
>
> sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
> is closing while the timer is running, it holds the same lock
> (lock_sock(sk)) twice, leading to a deadlock.
>
> CPU 0 CPU 1
> ==================== ======================
> sco_sock_close()
> sco_sock_timeout()
> lock_sock(sk) // <-- LOCK
> __sco_sock_close()
> sco_chan_del()
> sco_conn_put()
> sco_conn_free()
> disable_delayed_work_sync()
> lock(sk) // <-- SAME LOCK
>
> Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
> ensuring that no lock_sock(sk) is held before sco_sock_timeout().
>
> Lockdep splat:
>
> WARNING: possible circular locking dependency detected
> 6.13.0-rc4 #7 Not tainted
>
> syz-executor292/9514 is trying to acquire lock:
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
>
> but task is already holding lock:
> ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
> ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
> lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
> lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
> lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
> sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
> process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
> process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
> worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
> kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
> ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
>
> -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
> check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
> check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
> validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
> __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
> lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
> touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
> start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
> __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
> __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
> disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
> sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
> kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
> sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
> sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
> sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
> sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300
> __sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640
> sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408
> __fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450
> __fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535
> __do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline]
> __se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline]
> __x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539
> do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn")
> Acked-by: Dave Tian <daveti@purdue.edu>
> Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
> ---
> net/bluetooth/sco.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index fcc597be5bbd..c05f79b7aa31 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -570,10 +570,23 @@ static void __sco_sock_close(struct sock *sk)
> /* Must be called on unlocked socket. */
> static void sco_sock_close(struct sock *sk)
> {
> + struct sco_conn *conn;
> +
> + lock_sock(sk);
> + conn = sco_pi(sk)->conn;
> + if (conn)
> + sco_conn_hold(conn);
> + release_sock(sk);
> +
> + if (conn)
> + disable_delayed_work_sync(&conn->timeout_work);
> +
> lock_sock(sk);
> - sco_sock_clear_timer(sk);
> __sco_sock_close(sk);
> release_sock(sk);
> +
> + if (conn)
> + sco_conn_put(conn);
> }
>
> static void sco_sock_init(struct sock *sk, struct sock *parent)
> --
> 2.47.3
>
Although Sashiko [1] pointed out some interesting bugs in this patch,
they appear to be pre-existing.
I can send another patch for this.
[1] https://sashiko.dev/#/patchset/20260624213304.1460149-2-iam%40sung-woo.kim
^ permalink raw reply
* [PATCH] Bluetooth: sco: Fix a race condition in sco_sock_timeout()
From: Sungwoo Kim @ 2026-06-24 21:33 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Sungwoo Kim, Dave Tian, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel
sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
is closing while the timer is running, it holds the same lock
(lock_sock(sk)) twice, leading to a deadlock.
CPU 0 CPU 1
==================== ======================
sco_sock_close()
sco_sock_timeout()
lock_sock(sk) // <-- LOCK
__sco_sock_close()
sco_chan_del()
sco_conn_put()
sco_conn_free()
disable_delayed_work_sync()
lock(sk) // <-- SAME LOCK
Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
ensuring that no lock_sock(sk) is held before sco_sock_timeout().
Lockdep splat:
WARNING: possible circular locking dependency detected
6.13.0-rc4 #7 Not tainted
syz-executor292/9514 is trying to acquire lock:
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
but task is already holding lock:
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
-> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
__lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
__flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
__cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300
__sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640
sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408
__fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450
__fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535
__do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline]
__se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline]
__x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539
do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn")
Acked-by: Dave Tian <daveti@purdue.edu>
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
---
net/bluetooth/sco.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index fcc597be5bbd..c05f79b7aa31 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -570,10 +570,23 @@ static void __sco_sock_close(struct sock *sk)
/* Must be called on unlocked socket. */
static void sco_sock_close(struct sock *sk)
{
+ struct sco_conn *conn;
+
+ lock_sock(sk);
+ conn = sco_pi(sk)->conn;
+ if (conn)
+ sco_conn_hold(conn);
+ release_sock(sk);
+
+ if (conn)
+ disable_delayed_work_sync(&conn->timeout_work);
+
lock_sock(sk);
- sco_sock_clear_timer(sk);
__sco_sock_close(sk);
release_sock(sk);
+
+ if (conn)
+ sco_conn_put(conn);
}
static void sco_sock_init(struct sock *sk, struct sock *parent)
--
2.47.3
^ permalink raw reply related
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114334
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]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114528
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]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1115319
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 BlueZ] unit: test-bap: disable optimization to speed up compilation
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <e0650488e684f464f69cf013d1654f46bb862d46.1782046466.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 21 Jun 2026 15:54:34 +0300 you wrote:
> Compilation of this file with optimization takes 12 min with ASAN, 1 min
> without. This is too long, and the -O2 doesn't serve purpose for unit
> tests.
>
> Disable optimization to reduce to 30 sec with ASAN (5 sec without).
>
> autoconf puts global -O2 in CFLAGS that cannot be overridden eg. with
> unit_test_bap_CFLAGS. Use pragma instead.
>
> [...]
Here is the summary with links:
- [BlueZ] unit: test-bap: disable optimization to speed up compilation
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=eb9b35c8d13d
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 BlueZ v1] shared/rap: Fix step payload pointer in parse_step
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Prathibha Madugonde
Cc: linux-bluetooth, luiz.dentz, quic_mohamull, quic_hbandi,
quic_anubhavg
In-Reply-To: <20260623111112.1332742-1-prathm@qti.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 23 Jun 2026 16:41:12 +0530 you wrote:
> From: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
>
> util_iov_pull advances iov_base before returning the new pointer, so
> mode_iov.iov_base was set to the start of the *next* step's data.
> Every step was therefore parsed using its successor's bytes.
>
> Switch to util_iov_pull_mem which saves the original base, advances
> iov, and returns the pre-advance pointer — correctly pointing to the
> current step's payload.
>
> [...]
Here is the summary with links:
- [BlueZ,v1] shared/rap: Fix step payload pointer in parse_step
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=40a58272a58f
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 BlueZ v1] shared: rap: Defer CS Event registration until connection setup
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Naga Bhavani Akella
Cc: linux-bluetooth, luiz.dentz, quic_mohamull, quic_hbandi,
quic_anubhavg
In-Reply-To: <20260622062905.3525480-1-naga.akella@oss.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 22 Jun 2026 11:59:05 +0530 you wrote:
> Move LE CS event registration from rap_probe()
> to rap_accept(). rap_probe() runs during service discovery
> while no ACL connection or connection handle exists,
> so connection-scoped CS events cannot be delivered or
> associated with a device. rap_accept() is called
> after the ACL link is established, when a valid
> connection handle is available and the HCI layer
> can route events correctly.
> Registering events at this point ensures
> proper handling of CS events.
>
> [...]
Here is the summary with links:
- [BlueZ,v1] shared: rap: Defer CS Event registration until connection setup
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=7efd9383f0a1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [bluez/bluez] 7efd93: shared: rap: Defer CS Event registration until con...
From: Pauli Virtanen @ 2026-06-24 17:44 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 7efd9383f0a1ea20226c63494bc0bcb9a3e2a8fa
https://github.com/bluez/bluez/commit/7efd9383f0a1ea20226c63494bc0bcb9a3e2a8fa
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M profiles/ranging/rap.c
Log Message:
-----------
shared: rap: Defer CS Event registration until connection setup
Move LE CS event registration from rap_probe()
to rap_accept(). rap_probe() runs during service discovery
while no ACL connection or connection handle exists,
so connection-scoped CS events cannot be delivered or
associated with a device. rap_accept() is called
after the ACL link is established, when a valid
connection handle is available and the HCI layer
can route events correctly.
Registering events at this point ensures
proper handling of CS events.
Commit: 40a58272a58fdfb00081289ab41fa6d4cebfb935
https://github.com/bluez/bluez/commit/40a58272a58fdfb00081289ab41fa6d4cebfb935
Author: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M src/shared/rap.c
Log Message:
-----------
shared/rap: Fix step payload pointer in parse_step
util_iov_pull advances iov_base before returning the new pointer, so
mode_iov.iov_base was set to the start of the *next* step's data.
Every step was therefore parsed using its successor's bytes.
Switch to util_iov_pull_mem which saves the original base, advances
iov, and returns the pre-advance pointer — correctly pointing to the
current step's payload.
Commit: eb9b35c8d13dffcaf4f6f4b5bee29a18c860ba04
https://github.com/bluez/bluez/commit/eb9b35c8d13dffcaf4f6f4b5bee29a18c860ba04
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M unit/test-bap.c
Log Message:
-----------
unit: test-bap: disable optimization to speed up compilation
Compilation of this file with optimization takes 12 min with ASAN, 1 min
without. This is too long, and the -O2 doesn't serve purpose for unit
tests.
Disable optimization to reduce to 30 sec with ASAN (5 sec without).
autoconf puts global -O2 in CFLAGS that cannot be overridden eg. with
unit_test_bap_CFLAGS. Use pragma instead.
Compare: https://github.com/bluez/bluez/compare/912f5efb0dd9...eb9b35c8d13d
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-24 17:07 UTC (permalink / raw)
To: Sherry Sun
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <VI0PR04MB121147C305022511469FB603A92ED2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
> >
> > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > From: Sherry Sun <sherry.sun@nxp.com>
> > >
> > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > > suspend to preserve wakeup capability of the devices and also not to
> > > power on the devices in the init path.
> > > This allows controller power-off to be skipped when some devices(e.g.
> > > M.2 cards key E without auxiliary power) required to support PCIe L2
> > > link state and wake-up mechanisms.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > +++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> > *pp)
> > > }
> > > }
> > >
> > > - ret = pci_pwrctrl_create_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > - goto err_reg_disable;
> > > + if (!pci->suspended) {
> > > + ret = pci_pwrctrl_create_devices(dev);
> >
> > Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
> >
> > and call it direct at probe() function, like other regulator_get function.
> >
>
> Hi Frank,
> That makes sense. However, if we move pci_pwrctrl_create_devices () to
> probe(), we may need to add the following goto err_pwrctrl_destroy path
> in imx_pcie_probe() to properly handle errors from
> pci_pwrctrl_power_on_devices(), is that acceptable?
Can you add a API devm_pci_pwrctrl_create_devices() ?
Frank
>
> @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1991,6 +1984,11 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
> }
>
> Best Regards
> Sherry
>
> >
> > > + if (ret) {
> > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > + goto err_reg_disable;
> > > + }
> > > }
> > >
> > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > - goto err_pwrctrl_destroy;
> > > + if (!pp->skip_pwrctrl_off) {
> > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > + goto err_pwrctrl_destroy;
> > > + }
> > > }
> > >
> > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > static
> > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > err_clk_disable:
> > > imx_pcie_clk_disable(imx_pcie);
> > > err_pwrctrl_power_off:
> > > - pci_pwrctrl_power_off_devices(dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(dev);
> > > err_pwrctrl_destroy:
> > > - if (ret != -EPROBE_DEFER)
> > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > pci_pwrctrl_destroy_devices(dev);
> > > err_reg_disable:
> > > if (imx_pcie->vpcie)
> > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> > *pp)
> > > }
> > > imx_pcie_clk_disable(imx_pcie);
> > >
> > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > + if (!pci->pp.skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > if (imx_pcie->vpcie)
> > > regulator_disable(imx_pcie->vpcie);
> > > }
> > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > platform_device *pdev) {
> > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct dw_pcie_rp *pp = &pci->pp;
> > >
> > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > imx_pcie_assert_core_reset(imx_pcie);
> > > imx_pcie_assert_perst(imx_pcie, true);
> > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > + if (!pci->suspended)
> > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > }
> > >
> > > static const struct imx_pcie_drvdata drvdata[] = {
> > > --
> > > 2.50.1
> > >
> > >
^ permalink raw reply
* RE: [v2] Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: bluez.test.bot @ 2026-06-24 16:39 UTC (permalink / raw)
To: linux-bluetooth, sammiee5311
In-Reply-To: <20260624143222.883120-1-sammiee5311@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=1115967
---Test result---
Test Summary:
CheckPatch PASS 1.15 seconds
VerifyFixes PASS 0.34 seconds
VerifySignedoff PASS 0.34 seconds
GitLint PASS 0.54 seconds
SubjectPrefix PASS 0.80 seconds
BuildKernel PASS 26.37 seconds
CheckAllWarning PASS 28.90 seconds
CheckSparse PASS 28.03 seconds
BuildKernel32 PASS 25.68 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 567.29 seconds
TestRunner_l2cap-tester PASS 57.85 seconds
TestRunner_iso-tester PASS 98.51 seconds
TestRunner_bnep-tester PASS 18.83 seconds
TestRunner_mgmt-tester FAIL 214.90 seconds
TestRunner_rfcomm-tester PASS 25.00 seconds
TestRunner_sco-tester PASS 32.03 seconds
TestRunner_ioctl-tester PASS 25.36 seconds
TestRunner_mesh-tester FAIL 25.01 seconds
TestRunner_smp-tester PASS 23.05 seconds
TestRunner_userchan-tester PASS 19.97 seconds
TestRunner_6lowpan-tester PASS 22.74 seconds
IncrementalBuild PASS 25.12 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.248 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.986 seconds
Mesh - Send cancel - 2 Timed out 1.990 seconds
https://github.com/bluez/bluetooth-next/pull/348
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 15:53 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100512
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
* [PATCH v2] Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: HyeongJun An @ 2026-06-24 14:32 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, HyeongJun An, stable
In-Reply-To: <20260624115439.868817-1-sammiee5311@gmail.com>
eir_get_service_data() walks the advertising data looking for a Service
Data field with a matching UUID. eir_get_data() returns a pointer to the
matched field's data (field + 2) and reports dlen = field_len - 1 (the
data length only), while the field actually spans field_len + 1 = dlen + 2
bytes once its length and type bytes are counted.
On a UUID mismatch the loop advances:
eir += dlen;
eir_len -= dlen;
The pointer advance is correct, but eir_len is decremented by only dlen --
2 less than the bytes the field really spans (and less still when
eir_get_data() skipped preceding non-Service-Data fields). eir_len thus
over-counts the remaining buffer, and the error compounds across fields.
As eir_get_data() bounds its walk by this inflated eir_len, it ends up
reading the length/type bytes of a "field" past the end of the buffer.
For an ISO broadcast sink the buffer is hcon->le_per_adv_data[], filled
from the periodic-advertising reports of a remote broadcaster and parsed
by eir_get_service_data() in net/bluetooth/iso.c. A crafted PA payload
packed with mismatching Service Data fields drives the walk past the
array into adjacent struct hci_conn memory -- a remotely triggerable
out-of-bounds read; when a drifted field happens to match the BAA UUID
the out-of-bounds bytes are copied into iso_pi(sk)->base and become
readable from user space via getsockopt(BT_ISO_BASE).
Keep eir_len in sync with the pointer by recomputing it from the end of
the buffer on each iteration.
Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
---
Changes in v2:
- Untab the commit-message code snippet to satisfy the gitlint check; no
code change.
net/bluetooth/eir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c
index 1de5f9df6eec..a55696820b22 100644
--- a/net/bluetooth/eir.c
+++ b/net/bluetooth/eir.c
@@ -369,6 +369,7 @@ u8 eir_create_scan_rsp(struct hci_dev *hdev, u8 instance, u8 *ptr)
void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
{
+ const u8 *eir_end = eir + eir_len;
size_t dlen;
while ((eir = eir_get_data(eir, eir_len, EIR_SERVICE_DATA, &dlen))) {
@@ -381,7 +382,7 @@ void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
}
eir += dlen;
- eir_len -= dlen;
+ eir_len = eir_end - eir;
}
return NULL;
--
2.43.0
^ permalink raw reply related
* RE: Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: bluez.test.bot @ 2026-06-24 14:19 UTC (permalink / raw)
To: linux-bluetooth, sammiee5311
In-Reply-To: <20260624115439.868817-1-sammiee5311@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2653 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=1115877
---Test result---
Test Summary:
CheckPatch PASS 1.35 seconds
VerifyFixes PASS 0.31 seconds
VerifySignedoff PASS 0.20 seconds
GitLint FAIL 0.71 seconds
SubjectPrefix PASS 0.37 seconds
BuildKernel PASS 27.00 seconds
CheckAllWarning PASS 29.24 seconds
CheckSparse PASS 27.97 seconds
BuildKernel32 PASS 25.97 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 574.54 seconds
TestRunner_l2cap-tester PASS 57.98 seconds
TestRunner_iso-tester PASS 78.50 seconds
TestRunner_bnep-tester PASS 18.88 seconds
TestRunner_mgmt-tester FAIL 209.96 seconds
TestRunner_rfcomm-tester PASS 25.44 seconds
TestRunner_sco-tester PASS 32.55 seconds
TestRunner_ioctl-tester PASS 25.60 seconds
TestRunner_mesh-tester FAIL 26.07 seconds
TestRunner_smp-tester PASS 22.95 seconds
TestRunner_userchan-tester PASS 19.95 seconds
TestRunner_6lowpan-tester PASS 22.94 seconds
IncrementalBuild PASS 25.85 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: eir: Fix OOB read in eir_get_service_data()
11: B3 Line contains hard tab characters (\t): " eir += dlen;"
12: B3 Line contains hard tab characters (\t): " eir_len -= dlen;"
##############################
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.233 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.439 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
https://github.com/bluez/bluetooth-next/pull/347
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v8] Bluetooth: btbcm: Add Synaptics 4384 chip support
From: Paul Menzel @ 2026-06-24 12:30 UTC (permalink / raw)
To: Kaihsin Chung
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, Kaihsin Chung
In-Reply-To: <20260624081947.2495351-1-kaihsin.chung@synaptics.com>
Dear Kaihsin,
Thank you for your patch. Just a note, that your given name should also
start with a capital letter.
Am 24.06.26 um 10:19 schrieb kaihsin Chung:
> Add support for the Synaptics 4384 Bluetooth controller
> by adding the corresponding chip IDs.
Please mention the source for the ids, like a datasheet name.
Also, please document in the commit message, how you tested this.
> Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
> ---
> drivers/bluetooth/btbcm.c | 6 +++++-
> drivers/bluetooth/hci_bcm.c | 1 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
> index 463d59890bef..1caa1c9468d8 100644
> --- a/drivers/bluetooth/btbcm.c
> +++ b/drivers/bluetooth/btbcm.c
> @@ -31,6 +31,7 @@
> #define BDADDR_BCM4334B0 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb0, 0x34, 0x43}})
> #define BDADDR_BCM4345C5 (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0xc5, 0x45, 0x43}})
> #define BDADDR_BCM43341B (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0x1b, 0x34, 0x43}})
> +#define BDADDR_BCM4384B0 (&(bdaddr_t) {{0x93, 0x76, 0x00, 0xb0, 0x84, 0x43}})
>
> #define BCM_FW_NAME_LEN 64
> #define BCM_FW_NAME_COUNT_MAX 4
> @@ -130,7 +131,8 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
> !bacmp(&bda->bdaddr, BDADDR_BCM4345C5) ||
> !bacmp(&bda->bdaddr, BDADDR_BCM43430A0) ||
> !bacmp(&bda->bdaddr, BDADDR_BCM43430A1) ||
> - !bacmp(&bda->bdaddr, BDADDR_BCM43341B)) {
> + !bacmp(&bda->bdaddr, BDADDR_BCM43341B) ||
> + !bacmp(&bda->bdaddr, BDADDR_BCM4384B0)) {
> /* Try falling back to BDADDR EFI variable */
> if (btbcm_set_bdaddr_from_efi(hdev) != 0) {
> bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
> @@ -514,6 +516,8 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
> { 0x4106, "BCM4335A0" }, /* 002.001.006 */
> { 0x410c, "BCM43430B0" }, /* 002.001.012 */
> { 0x2119, "BCM4373A0" }, /* 001.001.025 */
> + { 0x2128, "BCM4384A0" },/* 001.001.040 */
> + { 0x4119, "BCM4384B0"},/* 002.001.025 */
Please align everything with the existing lines (} and /*).
> { }
> };
>
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index 1a4fc3882fd2..d306da6a46ff 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -1594,6 +1594,7 @@ static const struct of_device_id bcm_bluetooth_of_match[] = {
> { .compatible = "brcm,bcm4335a0" },
> { .compatible = "cypress,cyw4373a0-bt", .data = &cyw4373a0_device_data },
> { .compatible = "infineon,cyw55572-bt", .data = &cyw55572_device_data },
> + { .compatible = "brcm,bcm4384-bt" },
Put it two lines above below the existing brcm line?
> { },
> };
> MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match);
Kind regards,
Paul
^ permalink raw reply
* RE: Bluetooth: virtio_bt: unregister HCI device on open failure
From: bluez.test.bot @ 2026-06-24 11:57 UTC (permalink / raw)
To: linux-bluetooth, haoxiang_li2024
In-Reply-To: <20260624084333.2885144-1-haoxiang_li2024@163.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=1115809
---Test result---
Test Summary:
CheckPatch PASS 0.77 seconds
VerifyFixes PASS 0.27 seconds
VerifySignedoff PASS 0.17 seconds
GitLint PASS 0.47 seconds
SubjectPrefix PASS 0.20 seconds
BuildKernel PASS 20.84 seconds
CheckAllWarning PASS 23.20 seconds
CheckSparse PASS 31.01 seconds
BuildKernel32 PASS 20.39 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 414.24 seconds
IncrementalBuild PASS 19.89 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/346
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: HyeongJun An @ 2026-06-24 11:54 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, HyeongJun An, stable
eir_get_service_data() walks the advertising data looking for a Service
Data field with a matching UUID. eir_get_data() returns a pointer to the
matched field's data (field + 2) and reports dlen = field_len - 1 (the
data length only), while the field actually spans field_len + 1 = dlen + 2
bytes once its length and type bytes are counted.
On a UUID mismatch the loop advances:
eir += dlen;
eir_len -= dlen;
The pointer advance is correct, but eir_len is decremented by only dlen --
2 less than the bytes the field really spans (and less still when
eir_get_data() skipped preceding non-Service-Data fields). eir_len thus
over-counts the remaining buffer, and the error compounds across fields.
As eir_get_data() bounds its walk by this inflated eir_len, it ends up
reading the length/type bytes of a "field" past the end of the buffer.
For an ISO broadcast sink the buffer is hcon->le_per_adv_data[], filled
from the periodic-advertising reports of a remote broadcaster and parsed
by eir_get_service_data() in net/bluetooth/iso.c. A crafted PA payload
packed with mismatching Service Data fields drives the walk past the
array into adjacent struct hci_conn memory -- a remotely triggerable
out-of-bounds read; when a drifted field happens to match the BAA UUID
the out-of-bounds bytes are copied into iso_pi(sk)->base and become
readable from user space via getsockopt(BT_ISO_BASE).
Keep eir_len in sync with the pointer by recomputing it from the end of
the buffer on each iteration.
Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
---
net/bluetooth/eir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c
index 1de5f9df6eec..a55696820b22 100644
--- a/net/bluetooth/eir.c
+++ b/net/bluetooth/eir.c
@@ -369,6 +369,7 @@ u8 eir_create_scan_rsp(struct hci_dev *hdev, u8 instance, u8 *ptr)
void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
{
+ const u8 *eir_end = eir + eir_len;
size_t dlen;
while ((eir = eir_get_data(eir, eir_len, EIR_SERVICE_DATA, &dlen))) {
@@ -381,7 +382,7 @@ void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
}
eir += dlen;
- eir_len -= dlen;
+ eir_len = eir_end - eir;
}
return NULL;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: virtio_bt: unregister HCI device on open failure
From: Dan Carpenter @ 2026-06-24 10:56 UTC (permalink / raw)
To: Haoxiang Li
Cc: marcel, luiz.dentz, yangyingliang, mst, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <20260624084333.2885144-1-haoxiang_li2024@163.com>
On Wed, Jun 24, 2026 at 04:43:33PM +0800, Haoxiang Li wrote:
> virtbt_probe() registers the HCI device before calling
> virtbt_open_vdev(). If opening the virtio Bluetooth
> device fails, the error path frees the HCI device without
> unregistering it.
>
> Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/bluetooth/virtio_bt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
> index 140ab55c9fc5..bf6827431bb8 100644
> --- a/drivers/bluetooth/virtio_bt.c
> +++ b/drivers/bluetooth/virtio_bt.c
> @@ -397,6 +397,7 @@ static int virtbt_probe(struct virtio_device *vdev)
> return 0;
>
> open_failed:
> + hci_unregister_dev(hdev);
> hci_free_dev(hdev);
> failed:
> vdev->config->del_vqs(vdev);
I have written a blog about how to write error handling.
https://staticthinking.wordpress.com/2022/04/28/free-the-last-thing-style/
Originally this code using One Err style error handling where every
error path just did "goto fail". It's also using ComeFrom label names
which don't say what the goto does only where the goto is... Ideally if
hci_register_dev() failed it would use the unwind ladder to clean up it
instead calls hci_free_dev() and then goto fail.
The beauty of writing a normal kernel style unwind ladder is that it
writes the cleanup function automatically... Let's look at the cleanup
function here.
406 static void virtbt_remove(struct virtio_device *vdev)
407 {
408 struct virtio_bluetooth *vbt = vdev->priv;
409 struct hci_dev *hdev = vbt->hdev;
410
411 hci_unregister_dev(hdev);
412 virtio_reset_device(vdev);
413 virtbt_close_vdev(vbt);
I'm really uncomfortable with having the hci_unregister_dev()
before the close. Potential use after free?
414
415 hci_free_dev(hdev);
416 vbt->hdev = NULL;
417
418 vdev->config->del_vqs(vdev);
419 kfree(vbt);
The probe function should free "vbt" but it doesn't so that's
another leak.
420 }
So this fix is fine but it's also only a partial fix.
regards,
dan carpenter
^ permalink raw reply
* RE: Bluetooth: btmtk: Add MT7928 support
From: bluez.test.bot @ 2026-06-24 9:14 UTC (permalink / raw)
To: linux-bluetooth, chris.lu
In-Reply-To: <20260624075505.1318804-2-chris.lu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2650 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=1115762
---Test result---
Test Summary:
CheckPatch PASS 4.09 seconds
VerifyFixes PASS 0.52 seconds
VerifySignedoff PASS 0.60 seconds
GitLint FAIL 1.96 seconds
SubjectPrefix PASS 0.69 seconds
BuildKernel PASS 26.78 seconds
CheckAllWarning PASS 29.55 seconds
CheckSparse PASS 28.50 seconds
BuildKernel32 PASS 25.87 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 568.81 seconds
IncrementalBuild PASS 31.08 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v5,2/3] Bluetooth: btmtk: Improve BT firmware logging
11: B1 Line exceeds max length (92>80): "[ 212.878783] Bluetooth: hci1: Loading BT firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin"
12: B1 Line exceeds max length (93>80): "[ 212.889614] Bluetooth: hci1: BT HW ver: 0x7922, SW ver: 0x008a, Build Time: 20260224103448"
14: B1 Line exceeds max length (115>80): "[ 216.048890] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported."
[v5,3/3] Bluetooth: btmtk: Add MT7928 support
24: B1 Line exceeds max length (92>80): "[ 159.784050] usb 1-3: New USB device found, idVendor=0e8d, idProduct=7935, bcdDevice= 1.00"
29: B1 Line exceeds max length (97>80): "[ 159.795736] Bluetooth: hci1: Loading CBMCU firmware: mediatek/mt7928/CBMCU_CODE_MT7935_1_1.bin"
30: B1 Line exceeds max length (102>80): "[ 159.807197] Bluetooth: hci1: CBMCU HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260601T161751+0800"
32: B1 Line exceeds max length (99>80): "[ 160.143013] Bluetooth: hci1: Loading BT firmware: mediatek/mt7928/BT_RAM_CODE_MT7935_1_1_hdr.bin"
33: B1 Line exceeds max length (93>80): "[ 160.152775] Bluetooth: hci1: BT HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260527000816"
35: B1 Line exceeds max length (115>80): "[ 163.242280] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported."
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/344
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v8] Bluetooth: btbcm: Add Synaptics 4384 chip support
From: bluez.test.bot @ 2026-06-24 9:14 UTC (permalink / raw)
To: linux-bluetooth, kaihsin.chung
In-Reply-To: <20260624081947.2495351-1-kaihsin.chung@synaptics.com>
[-- Attachment #1: Type: text/plain, Size: 2102 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=1115763
---Test result---
Test Summary:
CheckPatch FAIL 1.82 seconds
VerifyFixes PASS 0.26 seconds
VerifySignedoff PASS 0.34 seconds
GitLint PASS 0.55 seconds
SubjectPrefix PASS 0.21 seconds
BuildKernel PASS 27.26 seconds
CheckAllWarning PASS 30.15 seconds
CheckSparse PASS 29.67 seconds
BuildKernel32 PASS 27.48 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 574.79 seconds
IncrementalBuild PASS 26.11 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v8] Bluetooth: btbcm: Add Synaptics 4384 chip support
WARNING: DT compatible string "brcm,bcm4384-bt" appears un-documented -- check ./Documentation/devicetree/bindings/
#154: FILE: drivers/bluetooth/hci_bcm.c:1597:
+ { .compatible = "brcm,bcm4384-bt" },
ERROR: Missing Signed-off-by: line by nominal patch author 'kaihsin Chung <kaihsin.chung@synaptics.corp-partner.google.com>'
total: 1 errors, 1 warnings, 31 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/14642410.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/345
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v5] Bluetooth: btrtl: Add firmware format v3 support
From: bluez.test.bot @ 2026-06-24 9:14 UTC (permalink / raw)
To: linux-bluetooth, hildawu
In-Reply-To: <20260624053334.3151885-1-hildawu@realtek.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=1115683
---Test result---
Test Summary:
CheckPatch PASS 2.58 seconds
VerifyFixes PASS 0.24 seconds
VerifySignedoff PASS 0.25 seconds
GitLint PASS 0.56 seconds
SubjectPrefix PASS 0.36 seconds
BuildKernel PASS 26.77 seconds
CheckAllWarning PASS 29.75 seconds
CheckSparse PASS 28.35 seconds
BuildKernel32 PASS 26.19 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 574.02 seconds
IncrementalBuild PASS 25.77 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/343
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: virtio_bt: unregister HCI device on open failure
From: Paul Menzel @ 2026-06-24 9:10 UTC (permalink / raw)
To: Haoxiang Li
Cc: marcel, luiz.dentz, yangyingliang, mst, error27, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <20260624084333.2885144-1-haoxiang_li2024@163.com>
Dear Haoxiang,
Thank you for your patch.
Am 24.06.26 um 10:43 schrieb Haoxiang Li:
> virtbt_probe() registers the HCI device before calling
> virtbt_open_vdev(). If opening the virtio Bluetooth
> device fails, the error path frees the HCI device without
> unregistering it.
Should you resend, please re-flow for 72/75 characters, so only three
lines are used.
> Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/bluetooth/virtio_bt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
> index 140ab55c9fc5..bf6827431bb8 100644
> --- a/drivers/bluetooth/virtio_bt.c
> +++ b/drivers/bluetooth/virtio_bt.c
> @@ -397,6 +397,7 @@ static int virtbt_probe(struct virtio_device *vdev)
> return 0;
>
> open_failed:
> + hci_unregister_dev(hdev);
> hci_free_dev(hdev);
> failed:
> vdev->config->del_vqs(vdev);
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
PS: gemini/gemini-3.1-pro-preview found an unrelated issue to the patch
during review of this patch [1].
> This is a pre-existing issue, but does this error path safely clean up the
> active virtqueues?
> Earlier in virtbt_probe(), virtio_device_ready(vdev) marks the device as
> active. If virtbt_open_vdev() subsequently fails, the code jumps to the
> open_failed label and eventually reaches here to call del_vqs(vdev).
> Deleting virtqueues without calling virtio_reset_device(vdev) first violates
> the VirtIO API contract for active devices. It could allow the host or
> hypervisor to access guest memory that has already been freed by del_vqs(),
> potentially leading to a use-after-free.
> Should virtio_reset_device(vdev) be called before tearing down the
> virtqueues in this error path?
No idea, how to best track these things.
[1]:
https://sashiko.dev/#/patchset/20260624084333.2885144-1-haoxiang_li2024%40163.com
^ permalink raw reply
* [PATCH] Bluetooth: virtio_bt: unregister HCI device on open failure
From: Haoxiang Li @ 2026-06-24 8:43 UTC (permalink / raw)
To: marcel, luiz.dentz, yangyingliang, mst, error27
Cc: linux-bluetooth, linux-kernel, Haoxiang Li, stable
virtbt_probe() registers the HCI device before calling
virtbt_open_vdev(). If opening the virtio Bluetooth
device fails, the error path frees the HCI device without
unregistering it.
Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/bluetooth/virtio_bt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
index 140ab55c9fc5..bf6827431bb8 100644
--- a/drivers/bluetooth/virtio_bt.c
+++ b/drivers/bluetooth/virtio_bt.c
@@ -397,6 +397,7 @@ static int virtbt_probe(struct virtio_device *vdev)
return 0;
open_failed:
+ hci_unregister_dev(hdev);
hci_free_dev(hdev);
failed:
vdev->config->del_vqs(vdev);
--
2.25.1
^ permalink raw reply related
* [PATCH v8] Bluetooth: btbcm: Add Synaptics 4384 chip support
From: kaihsin Chung @ 2026-06-24 8:19 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.dentz, linux-kernel, kaihsin Chung
Add support for the Synaptics 4384 Bluetooth controller
by adding the corresponding chip IDs.
Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
---
drivers/bluetooth/btbcm.c | 6 +++++-
drivers/bluetooth/hci_bcm.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 463d59890bef..1caa1c9468d8 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -31,6 +31,7 @@
#define BDADDR_BCM4334B0 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb0, 0x34, 0x43}})
#define BDADDR_BCM4345C5 (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0xc5, 0x45, 0x43}})
#define BDADDR_BCM43341B (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0x1b, 0x34, 0x43}})
+#define BDADDR_BCM4384B0 (&(bdaddr_t) {{0x93, 0x76, 0x00, 0xb0, 0x84, 0x43}})
#define BCM_FW_NAME_LEN 64
#define BCM_FW_NAME_COUNT_MAX 4
@@ -130,7 +131,8 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
!bacmp(&bda->bdaddr, BDADDR_BCM4345C5) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A0) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A1) ||
- !bacmp(&bda->bdaddr, BDADDR_BCM43341B)) {
+ !bacmp(&bda->bdaddr, BDADDR_BCM43341B) ||
+ !bacmp(&bda->bdaddr, BDADDR_BCM4384B0)) {
/* Try falling back to BDADDR EFI variable */
if (btbcm_set_bdaddr_from_efi(hdev) != 0) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
@@ -514,6 +516,8 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
{ 0x4106, "BCM4335A0" }, /* 002.001.006 */
{ 0x410c, "BCM43430B0" }, /* 002.001.012 */
{ 0x2119, "BCM4373A0" }, /* 001.001.025 */
+ { 0x2128, "BCM4384A0" },/* 001.001.040 */
+ { 0x4119, "BCM4384B0"},/* 002.001.025 */
{ }
};
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 1a4fc3882fd2..d306da6a46ff 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1594,6 +1594,7 @@ static const struct of_device_id bcm_bluetooth_of_match[] = {
{ .compatible = "brcm,bcm4335a0" },
{ .compatible = "cypress,cyw4373a0-bt", .data = &cyw4373a0_device_data },
{ .compatible = "infineon,cyw55572-bt", .data = &cyw55572_device_data },
+ { .compatible = "brcm,bcm4384-bt" },
{ },
};
MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] Bluetooth: btrtl: Add firmware format v3 support
From: Paul Menzel @ 2026-06-24 8:06 UTC (permalink / raw)
To: Hilda Wu
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, alex_lu,
jason_mao, zoey_zhou, max.chou, kidman
In-Reply-To: <20260624053334.3151885-1-hildawu@realtek.com>
Dear Hilda,
Thank you for your patch.
Am 24.06.26 um 07:33 schrieb Hilda Wu:
> Realtek updated its Bluetooth firmware format to v3.
Please name the specification document, and state whether it’s
publically accessible.
> This patch extends the btrtl driver to recognise and parse the new v3 file
> format, including:
> - New signature string and image ID definitions
> - Extension of btrtl_device_info to store v3-specific metadata
> - Logic to extract and load firmware data out of v3 images
> - Maintains compatibility with existing v2 firmware format
>
> This is required for future Realtek Bluetooth chips that ship with
> v3 firmware.
Please add a blank line between paragraphs or do not wrap the line after
the sentence.
> The RTL8922D is the first IC to use firmware format V3, so the following
> example uses the RTL8922D's log as expected fw format v3 output:
>
> Bluetooth: btrtl_read_chip_id() hci0: RTL: chip_id status=0x00 id=0x37
> Bluetooth: btrtl_initialize() hci0: RTL: examining hci_ver=0d
> hci_rev=000d lmp_ver=0d lmp_subver=8922
Please do not wrap the lines of the pasted lines. If you keep the
timestamp in the front, `checkpatch.pl` should not complain.
> Bluetooth: rtl_read_rom_version() hci0: RTL: rom_version status=0 version=1
> Bluetooth: btrtl_initialize() hci0: RTL: btrtl_initialize: key id 0
> Bluetooth: rtl_load_file() hci0: RTL: loading rtl_bt/rtl8922du_fw.bin
> Bluetooth: rtl_load_file() hci0: RTL: loading rtl_bt/rtl8922du_config.bin
> Bluetooth: rtlbt_parse_firmware_v3() hci0: RTL: key id 0
> Bluetooth: rtlbt_parse_section_v3() hci0: RTL: image (f000:00), chip id
> 55, cut 0x02, len 00007185
> Bluetooth: rtlbt_parse_section_v3() hci0: RTL: image version: 35fd7908
> Bluetooth: rtlbt_parse_config() hci0: RTL: config file:
> rtl_bt/rtl8922du_config_f000.bin
> Bluetooth: rtlbt_parse_section_v3() hci0: RTL: image (f002:00), chip id
> 55, cut 0x02, len 000078f5
> Bluetooth: rtlbt_parse_section_v3() hci0: RTL: image version: 47b6874d
> Bluetooth: rtlbt_parse_config() hci0: RTL: config file:
> rtl_bt/rtl8922du_config_f002.bin
> Bluetooth: rtlbt_parse_firmware_v3() hci0: RTL: image payload total len:
> 0x0000ea7a
> Bluetooth: rtl_finalize_download() hci0: RTL: Watchdog reset status 00
> Bluetooth: rtl_finalize_download() hci0: RTL: fw version 0x47b6874d
How big in the firmware file, and how long did it take to load it?
> Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
> Signed-off-by: Zoey Zhou <zoey_zhou@realsil.com.cn>
> Signed-off-by: Hilda Wu <hildawu@realtek.com>
>
> ---
> V4 -> V5::
> - Add independent support for RTL8922D section
> - Introduce macros to improve code readability
> - Document firmware format v3 and its differences
> - Align implementation with reviewer feedback
>
> V3 -> V4:
> - Rework skb->data access and add clarifying comments
> - Fix latent issues
>
> V2 -> V3:
> - Address coccinelle warning
>
> V1 -> V2:
> - Add missing symbols
> - Resolve build warnings
> ---
> drivers/bluetooth/btrtl.c | 698 +++++++++++++++++++++++++++++++++++++-
> drivers/bluetooth/btrtl.h | 102 ++++++
The files get bigger. Would it be good to split the firmware handling
out into a separate file?
> drivers/bluetooth/btusb.c | 3 +
> 3 files changed, 786 insertions(+), 17 deletions(-)
For easier review, would it be possible to split out the refactoring
like defining the macros FW_TYPE_V0, … and using them?
[…]
Kind regards,
Paul
^ 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