Linux bluetooth development
 help / color / mirror / Atom feed
* RE: [1/4] Bluetooth: hci_sync: pin conn across hci_le_create_conn_sync
From: bluez.test.bot @ 2026-05-11 18:05 UTC (permalink / raw)
  To: linux-bluetooth, michael.bommarito
In-Reply-To: <490e228dd02983fb1530fb114d4174148f810261.1778506829.git.michael.bommarito@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3885 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=1092854

---Test result---

Test Summary:
CheckPatch                    PASS      2.15 seconds
GitLint                       FAIL      0.80 seconds
SubjectPrefix                 PASS      0.25 seconds
BuildKernel                   PASS      25.08 seconds
CheckAllWarning               PASS      27.34 seconds
CheckSparse                   PASS      26.59 seconds
BuildKernel32                 PASS      24.63 seconds
TestRunnerSetup               PASS      532.72 seconds
TestRunner_l2cap-tester       PASS      379.10 seconds
TestRunner_iso-tester         PASS      601.56 seconds
TestRunner_bnep-tester        PASS      19.56 seconds
TestRunner_mgmt-tester        PASS      2024.23 seconds
TestRunner_rfcomm-tester      PASS      63.47 seconds
TestRunner_sco-tester         PASS      141.37 seconds
TestRunner_ioctl-tester       PASS      133.62 seconds
TestRunner_mesh-tester        PASS      60.51 seconds
TestRunner_smp-tester         PASS      18.60 seconds
TestRunner_userchan-tester    PASS      20.23 seconds
TestRunner_6lowpan-tester     PASS      51.88 seconds
IncrementalBuild              PASS      32.90 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[1/4] Bluetooth: hci_sync: pin conn across hci_le_create_conn_sync

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
41: B1 Line exceeds max length (107>80): "https://lore.kernel.org/linux-bluetooth/e18591f264c50e15917cb8b9e5f9798d9880979d.1762100290.git.pav@iki.fi/"
[2/4] Bluetooth: hci_sync: pin conn across hci_le_pa_create_sync

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
25: B1 Line exceeds max length (108>80): "https://lore.kernel.org/linux-bluetooth/e18591f264c50e15917cb8b9e5f9798d9880979d.1762100290.git.pav@iki.fi/."
[3/4] Bluetooth: hci_sync: pin conn across hci_le_big_create_sync

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
25: B1 Line exceeds max length (108>80): "https://lore.kernel.org/linux-bluetooth/e18591f264c50e15917cb8b9e5f9798d9880979d.1762100290.git.pav@iki.fi/."
[4/4] Bluetooth: hci_sync: pin conn across hci_acl_create_conn_sync

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
29: B1 Line exceeds max length (108>80): "https://lore.kernel.org/linux-bluetooth/e18591f264c50e15917cb8b9e5f9798d9880979d.1762100290.git.pav@iki.fi/."


https://github.com/bluez/bluetooth-next/pull/169

---
Regards,
Linux Bluetooth


^ permalink raw reply

* RE: [v3] Bluetooth: 6lowpan: Fix peer and channel lifetime during teardown
From: bluez.test.bot @ 2026-05-11 18:44 UTC (permalink / raw)
  To: linux-bluetooth, rollkingzzc
In-Reply-To: <20260511172310.3723421-1-rollkingzzc@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 936 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=1092992

---Test result---

Test Summary:
CheckPatch                    PASS      0.82 seconds
GitLint                       PASS      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      26.14 seconds
CheckAllWarning               PASS      28.48 seconds
CheckSparse                   PASS      27.47 seconds
BuildKernel32                 PASS      25.15 seconds
TestRunnerSetup               PASS      559.53 seconds
TestRunner_6lowpan-tester     PASS      50.85 seconds
IncrementalBuild              PASS      24.94 seconds



https://github.com/bluez/bluetooth-next/pull/173

---
Regards,
Linux Bluetooth


^ permalink raw reply

* RE: Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: bluez.test.bot @ 2026-05-11 18:49 UTC (permalink / raw)
  To: linux-bluetooth, oss
In-Reply-To: <20260511170929.709823-2-oss@fourdim.xyz>

[-- Attachment #1: Type: text/plain, Size: 1708 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=1092984

---Test result---

Test Summary:
CheckPatch                    PASS      1.40 seconds
GitLint                       FAIL      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      26.78 seconds
CheckAllWarning               PASS      27.90 seconds
CheckSparse                   PASS      26.85 seconds
BuildKernel32                 PASS      24.71 seconds
TestRunnerSetup               PASS      524.97 seconds
TestRunner_l2cap-tester       PASS      376.41 seconds
TestRunner_smp-tester         PASS      18.41 seconds
TestRunner_6lowpan-tester     PASS      51.29 seconds
IncrementalBuild              PASS      23.95 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[RESEND,v4,1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (86>80): "[RESEND,v4,1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()"


https://github.com/bluez/bluetooth-next/pull/172

---
Regards,
Linux Bluetooth


^ permalink raw reply

* Re: [PATCH v1] Bluetooth: btintel_pcie: Simplify MAC access request/release
From: Paul Menzel @ 2026-05-11 19:10 UTC (permalink / raw)
  To: Kiran K; +Cc: linux-bluetooth, ravishankar.srivatsa, chethan.tumkur.narayan
In-Reply-To: <20260511133932.1217624-1-kiran.k@intel.com>

Dear Kiran,


Thank yuo for your patch.

Am 11.05.26 um 15:39 schrieb Kiran K:
> Drop the STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ bit manipulations from
> btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access().
> These bits are no longer required to be toggled by the host driver for
> MAC access on the supported parts; the controller manages them
> internally.

Does the “no longer” refer to some controller firmware update? Please 
elaborate. (I personally prefer that as much as possible is done outside 
the firmware.) Also, maybe be explicit, and mention, if having the code 
has any practical downsides.

> Also fix the idempotency check in btintel_pcie_get_mac_access(): only
> assert MAC_ACCESS_REQ if it is not already set, instead of keying the
> read-modify-write off the MAC_ACCESS_STS bit (which reflects grant,
> not request, state).

*Also* is a good indicator to make something a separate commit. Any 
reason to not do it?

> Remove the now-unused STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ register
> defines from btintel_pcie.h.
> 
> Signed-off-by: Kiran K <kiran.k@intel.com>

No Fixes: tag? At least the second issue sounds like something to backport.

> ---
>   drivers/bluetooth/btintel_pcie.c | 10 +---------
>   drivers/bluetooth/btintel_pcie.h |  3 ---
>   2 files changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
> index fda474406003..53a4ad80b871 100644
> --- a/drivers/bluetooth/btintel_pcie.c
> +++ b/drivers/bluetooth/btintel_pcie.c
> @@ -594,9 +594,7 @@ static int btintel_pcie_get_mac_access(struct btintel_pcie_data *data)
>   
>   	reg = btintel_pcie_rd_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG);
>   
> -	reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS;
> -	reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ;
> -	if ((reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS) == 0)
> +	if (!(reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ))
>   		reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ;
>   
>   	btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
> @@ -622,12 +620,6 @@ static void btintel_pcie_release_mac_access(struct btintel_pcie_data *data)
>   	if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ)
>   		reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ;
>   
> -	if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS)
> -		reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS;
> -
> -	if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ)
> -		reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ;
> -
>   	btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
>   }
>   
> diff --git a/drivers/bluetooth/btintel_pcie.h b/drivers/bluetooth/btintel_pcie.h
> index 2db85f71b2f8..7fc8c46ed689 100644
> --- a/drivers/bluetooth/btintel_pcie.h
> +++ b/drivers/bluetooth/btintel_pcie.h
> @@ -34,9 +34,6 @@
>   #define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS	(BIT(20))
>   
>   #define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ	(BIT(21))
> -/* Stop MAC Access disconnection request */
> -#define BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS	(BIT(22))
> -#define BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ		(BIT(23))
>   
>   #define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_STS	(BIT(28))
>   #define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_DISCON	(BIT(29))

The diff looks good.


Kind regards,

Paul

^ permalink raw reply

* Re: [PATCH RESEND v4 1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Luiz Augusto von Dentz @ 2026-05-11 19:17 UTC (permalink / raw)
  To: Siwei Zhang; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20260511170929.709823-2-oss@fourdim.xyz>

Hi,

On Mon, May 11, 2026 at 1:09 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> l2cap_sock_new_connection_cb() accesses l2cap_pi(sk)->chan after
> release_sock(parent). Once the parent lock is released, the child
> socket sk can be freed by another task.
>
> Save the channel pointer into a local variable while the parent lock
> is still held to prevent this.
>
> Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
> Cc: stable@kernel.org
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> ---
>  net/bluetooth/6lowpan.c    |  5 +++++
>  net/bluetooth/l2cap_core.c | 12 ++++++++++++
>  net/bluetooth/l2cap_sock.c | 13 ++++++++++++-
>  net/bluetooth/smp.c        |  5 +++++
>  4 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 23a229ab6a33..71c1c04b61e5 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -755,6 +755,11 @@ static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
>
>         BT_DBG("chan %p pchan %p", chan, pchan);
>
> +       /* Match the put that the caller of ops->new_connection() performs
> +        * once it is done with the returned channel pointer.
> +        */
> +       l2cap_chan_hold(chan);
> +
>         return chan;
>  }
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 7701528f1167..0f6c3c651207 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4071,6 +4071,9 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
>
>         __l2cap_chan_add(conn, chan);
>
> +       /* Drop the ops->new_connection() ref; conn list now pins chan. */
> +       l2cap_chan_put(chan);
> +
>         dcid = chan->scid;
>
>         __set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
> @@ -4970,6 +4973,9 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
>
>         __l2cap_chan_add(conn, chan);
>
> +       /* Drop the ops->new_connection() ref; conn list now pins chan. */
> +       l2cap_chan_put(chan);
> +
>         l2cap_le_flowctl_init(chan, __le16_to_cpu(req->credits));
>
>         dcid = chan->scid;
> @@ -5194,6 +5200,9 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
>
>                 __l2cap_chan_add(conn, chan);
>
> +               /* Drop the ops->new_connection() ref; conn list now pins chan. */
> +               l2cap_chan_put(chan);
> +
>                 l2cap_ecred_init(chan, __le16_to_cpu(req->credits));
>
>                 /* Init response */
> @@ -7407,6 +7416,9 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
>                         chan->dst_type = dst_type;
>
>                         __l2cap_chan_add(conn, chan);
> +
> +                       /* Drop the ops->new_connection() ref; conn list now pins chan. */
> +                       l2cap_chan_put(chan);
>                 }
>
>                 l2cap_chan_unlock(pchan);
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index cf590a67d364..295c79cf5cf3 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -1497,6 +1497,7 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
>  static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
>  {
>         struct sock *sk, *parent = chan->data;
> +       struct l2cap_chan *child_chan;
>
>         if (!parent)
>                 return NULL;
> @@ -1523,9 +1524,19 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
>
>         bt_accept_enqueue(parent, sk, false);
>
> +       child_chan = l2cap_pi(sk)->chan;
> +
> +       /* Pin the channel for the caller. Once release_sock(parent) returns,
> +        * userspace can accept(2) and immediately close(2) the child socket,
> +        * which would drop the socket's references on the channel and free
> +        * it before the caller (e.g. l2cap_connect_req()) is done using the
> +        * returned pointer. The matching put is the caller's responsibility.
> +        */
> +       l2cap_chan_hold(child_chan);

The entire problem might be solvable by not removing `list_add` from
`l2cap_create_chan`. This way, it only allocates but does not attach
to global_l until __l2cap_chan_add is called which then handles the
addition. Alternatively, we could allocate it first, given the
circular dependency involving `l2cap_core`.c->l2cap_sock.c)
new_connection -> l2cap_chan_create(l2cap_sock.c->l2cap_core.c) which
makes the code rather hard to follow.

>         release_sock(parent);
>
> -       return l2cap_pi(sk)->chan;
> +       return child_chan;
>  }
>
>  static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 1739c1989dbd..9796c3030434 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -3231,6 +3231,11 @@ static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
>
>         BT_DBG("created chan %p", chan);
>
> +       /* Match the put that the caller of ops->new_connection() performs
> +        * once it is done with the returned channel pointer.
> +        */
> +       l2cap_chan_hold(chan);
> +
>         return chan;
>  }
>
> --
> 2.54.0
>


-- 
Luiz Augusto von Dentz

^ permalink raw reply

* Re: [PATCH v6] Bluetooth: hci_qca: Convert timeout from jiffies to ms
From: patchwork-bot+bluetooth @ 2026-05-11 19:30 UTC (permalink / raw)
  To: Shuai Zhang
  Cc: brgl, marcel, luiz.dentz, linux-arm-msm, linux-bluetooth,
	linux-kernel, cheng.jiang, quic_chezhou, wei.deng, jinwang.li,
	mengshi.wu, stable, pmenzel, bartosz.golaszewski
In-Reply-To: <20260511135837.3967550-1-shuai.zhang@oss.qualcomm.com>

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon, 11 May 2026 21:58:37 +0800 you wrote:
> Since the timer uses jiffies as its unit rather than ms, the timeout value
> must be converted from ms to jiffies when configuring the timer. Otherwise,
> the intended 8s timeout is incorrectly set to approximately 33s.
> 
> To improve readability, embed msecs_to_jiffies() directly in the macro
> definitions and drop the _MS suffix from macros that now yield jiffies
> values: MEMDUMP_TIMEOUT, FW_DOWNLOAD_TIMEOUT, IBS_DISABLE_SSR_TIMEOUT,
> CMD_TRANS_TIMEOUT, and IBS_BTSOC_TX_IDLE_TIMEOUT.
> 
> [...]

Here is the summary with links:
  - [v6] Bluetooth: hci_qca: Convert timeout from jiffies to ms
    https://git.kernel.org/bluetooth/bluetooth-next/c/c2f0079e8c42

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 v1] Bluetooth: btintel_pcie: Reset controller before configuring MSI-X
From: Paul Menzel @ 2026-05-11 20:49 UTC (permalink / raw)
  To: Kiran K
  Cc: linux-bluetooth, ravishankar.srivatsa, chethan.tumkur.narayan,
	aluvala.sai.teja
In-Reply-To: <20260511132711.1216139-1-kiran.k@intel.com>

Dear Kiran,


Thank you for your patch.

Am 11.05.26 um 15:27 schrieb Kiran K:
> From: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
> 
> Perform the shared hardware reset in btintel_pcie_probe() before
> configuring MSI-X so the controller starts from a known clean state.

Did you run into problems with the current ordering?

> While here, move btintel_pcie_config_msix() out of
> btintel_pcie_config_pcie() and into the probe sequence, and propagate
> errors from btintel_pcie_reset_bt() so probe fails cleanly if the
> shared HW reset does not complete.

“While here” also sounds to me to split the commit into two. But your call.

Please add a paragraph how to test it. (Maybe what log messages to look 
out for.) Is there a way to force `btintel_pcie_reset_bt()` to fail?

> Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
> Signed-off-by: Kiran K <kiran.k@intel.com>
> ---
>   drivers/bluetooth/btintel_pcie.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
> index fda474406003..6ff08de9ec78 100644
> --- a/drivers/bluetooth/btintel_pcie.c
> +++ b/drivers/bluetooth/btintel_pcie.c
> @@ -1646,9 +1646,6 @@ static int btintel_pcie_config_pcie(struct pci_dev *pdev,
>   	if (err)
>   		return err;
>   
> -	/* Configure MSI-X with causes list */
> -	btintel_pcie_config_msix(data);
> -
>   	return 0;
>   }
>   
> @@ -2659,6 +2656,14 @@ static int btintel_pcie_probe(struct pci_dev *pdev,
>   	if (err)
>   		goto exit_error;
>   
> +	err = btintel_pcie_reset_bt(data);
> +	if (err) {
> +		dev_err(&pdev->dev, "Bluetooth shared HW reset failed (%d)\n", err);

What is “shared HW reset”?

> +		goto exit_error;
> +	}
> +
> +	/* Configure MSI-X with causes list */
> +	btintel_pcie_config_msix(data);
>   	pci_set_drvdata(pdev, data);
>   
>   	err = btintel_pcie_alloc(data);


Kind regards,

Paul

^ permalink raw reply

* [PATCH BlueZ] adapter: add BCAA UUID also when seen device is not discoverable
From: Pauli Virtanen @ 2026-05-11 21:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Pauli Virtanen

BAP v1.0.2 Sec 6.4 specifies Broadcast discovery uses observation
procedure (Core Vol 3 Part C Sec 9.1.2) which makes no reference to
device discoverability state.

However, if remote device does:

1. Send Advertising Data for some other UUID with General Discoverable
2. Send Advertising Data for BCAA UUID with no flags

then adapter.c:btd_adapter_device_found() creates device in step 1. but
in step 2. it ignores the BCAA UUID since the device exists but is not
discoverable; the monitoring=true special case applies only for
first-seen devices.  Consequently bap plugin fails to pick up the BCAA
stream.

This sequence was observed to be produced by BlueZ + btvirt.

Fix by monitoring also previously existing but currently non-connectable
devices with BCAA UUID.

Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2812#note_3467783
Log:
--------------------------
@ MGMT Event: Device Found (0x0012) plen 17
        LE Address: 00:AA:01:00:00:42 (Intel Corporation)
        RSSI: invalid (0x7f)
        Flags: 0x00000000
        Data length: 3
        Data[3]:
        02 01 06                                         ...
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
...
@ MGMT Event: Device Found (0x0012) plen 39
        LE Address: 00:AA:01:00:00:42 (Intel Corporation)
        RSSI: invalid (0x7f)
        Flags: 0x00000004
          Not Connectable
        Data length: 25
        Data[25]:
        06 16 52 18 56 db 55 03 03 4e 18 0d 16 4e 18 00  ..R.V.U..N...N..
        ff 0f 0f 00 04 03 01 01 00                       .........
        Service Data: Broadcast Audio Announcement (0x1852)
        Broadcast ID: 5626710 (0x55db56)
        16-bit Service UUIDs (complete): 1 entry
          Audio Stream Control (0x184e)
        Service Data: Audio Stream Control (0x184e)
          Data[10]:
        00 ff 0f 0f 00 04 03 01 01 00
--------------------------
---
 src/adapter.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/adapter.c b/src/adapter.c
index 6df66b3e0..20f7c3e03 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -7360,6 +7360,14 @@ void btd_adapter_device_found(struct btd_adapter *adapter,
 	discoverable = device_is_discoverable(adapter, &eir_data, addr,
 						bdaddr_type, &auto_connect);
 
+	/* Monitor Devices advertising Broadcast Announcements if the
+	 * adapter is capable of synchronizing to it.
+	 */
+	if (eir_get_service_data(&eir_data, BCAA_SERVICE_UUID) &&
+					btd_adapter_has_settings(adapter,
+					MGMT_SETTING_ISO_SYNC_RECEIVER))
+		monitoring = true;
+
 	dev = btd_adapter_find_device(adapter, bdaddr, bdaddr_type);
 	if (!dev) {
 		/* In case of being just a scan response don't attempt to create
@@ -7370,14 +7378,6 @@ void btd_adapter_device_found(struct btd_adapter *adapter,
 			return;
 		}
 
-		/* Monitor Devices advertising Broadcast Announcements if the
-		 * adapter is capable of synchronizing to it.
-		 */
-		if (eir_get_service_data(&eir_data, BCAA_SERVICE_UUID) &&
-				btd_adapter_has_settings(adapter,
-				MGMT_SETTING_ISO_SYNC_RECEIVER))
-			monitoring = true;
-
 		/* If ISO  Socket is enabled, monitor Devices advertising RSI
 		 * since those can be coordinated sets not marked as visible but
 		 * their object are needed.
-- 
2.54.0


^ permalink raw reply related

* [bluez/bluez] 2c6d6b: adapter: add BCAA UUID also when seen device is no...
From: Pauli Virtanen @ 2026-05-11 22:19 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1093117
  Home:   https://github.com/bluez/bluez
  Commit: 2c6d6baaf29b7b7cf6cc44e9d26a0239bfbd3e19
      https://github.com/bluez/bluez/commit/2c6d6baaf29b7b7cf6cc44e9d26a0239bfbd3e19
  Author: Pauli Virtanen <pav@iki.fi>
  Date:   2026-05-11 (Mon, 11 May 2026)

  Changed paths:
    M src/adapter.c

  Log Message:
  -----------
  adapter: add BCAA UUID also when seen device is not discoverable

BAP v1.0.2 Sec 6.4 specifies Broadcast discovery uses observation
procedure (Core Vol 3 Part C Sec 9.1.2) which makes no reference to
device discoverability state.

However, if remote device does:

1. Send Advertising Data for some other UUID with General Discoverable
2. Send Advertising Data for BCAA UUID with no flags

then adapter.c:btd_adapter_device_found() creates device in step 1. but
in step 2. it ignores the BCAA UUID since the device exists but is not
discoverable; the monitoring=true special case applies only for
first-seen devices.  Consequently bap plugin fails to pick up the BCAA
stream.

This sequence was observed to be produced by BlueZ + btvirt.

Fix by monitoring also previously existing but currently non-connectable
devices with BCAA UUID.

Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2812#note_3467783
Log:
--------------------------
@ MGMT Event: Device Found (0x0012) plen 17
        LE Address: 00:AA:01:00:00:42 (Intel Corporation)
        RSSI: invalid (0x7f)
        Flags: 0x00000000
        Data length: 3
        Data[3]:
        02 01 06                                         ...
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
...
@ MGMT Event: Device Found (0x0012) plen 39
        LE Address: 00:AA:01:00:00:42 (Intel Corporation)
        RSSI: invalid (0x7f)
        Flags: 0x00000004
          Not Connectable
        Data length: 25
        Data[25]:
        06 16 52 18 56 db 55 03 03 4e 18 0d 16 4e 18 00  ..R.V.U..N...N..
        ff 0f 0f 00 04 03 01 01 00                       .........
        Service Data: Broadcast Audio Announcement (0x1852)
        Broadcast ID: 5626710 (0x55db56)
        16-bit Service UUIDs (complete): 1 entry
          Audio Stream Control (0x184e)
        Service Data: Audio Stream Control (0x184e)
          Data[10]:
        00 ff 0f 0f 00 04 03 01 01 00
--------------------------



To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications

^ permalink raw reply

* [PATCH AUTOSEL 7.0-6.18] Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
  To: patches, stable
  Cc: Aurelien DESBRIERES, syzbot+ff30eeab8e07b37d524e,
	Luiz Augusto von Dentz, Sasha Levin, marcel, johan.hedberg,
	luiz.dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>

From: Aurelien DESBRIERES <aurelien@hackers.camp>

[ Upstream commit 902fe40bce7059722f7ffa1c378e577675cf1918 ]

When a fault is injected during hci_uart line discipline setup, the
proto open() callback may fail leaving hu->priv as NULL. A subsequent
TIOCSTI ioctl can trigger the recv() callback before priv is
initialized, causing a NULL pointer dereference.

Fix all four affected HCI UART protocol drivers by adding a NULL check
on hu->priv at the start of their recv() callbacks: h4, h5, ath and
bcsp.

Reported-by: syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e
Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `Bluetooth: hci_uart`; action verb `Fix`;
intent is to prevent NULL dereference in HCI UART protocol `recv()`
callbacks when `hu->priv` is not initialized.

Step 1.2 Record: Tags found: `Reported-by:
syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com`; `Closes:
https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e`; `Signed-
off-by: Aurelien DESBRIERES`; `Assisted-by: Claude:claude-sonnet-4-6`;
`Signed-off-by: Luiz Augusto von Dentz`. No `Fixes:` tag. Notable
pattern: syzbot report with reproducer and KASAN NULL-deref crash.

Step 1.3 Record: The commit describes a `hu->priv == NULL` path during
HCI UART setup followed by received data via `TIOCSTI`, causing a NULL
pointer dereference. The syzkaller report verifies a KASAN NULL-
deref/general protection fault in `h4_recv`, with call chain `tty_ioctl
-> tiocsti -> hci_uart_tty_receive -> h4_recv`.

Step 1.4 Record: This is not hidden cleanup; it is an explicit memory-
safety crash fix. The added checks prevent dereferencing protocol-
private state when setup/error handling leaves it absent.

## Phase 2: Diff Analysis
Step 2.1 Record: Four files changed, all in `drivers/bluetooth`:
`hci_ath.c` `+3/-0`, `hci_bcsp.c` `+3/-0`, `hci_h4.c` `+3/-0`,
`hci_h5.c` `+3/-0`; total `12` insertions. Modified functions:
`ath_recv`, `bcsp_recv`, `h4_recv`, `h5_recv`. Scope: small multi-file
surgical driver fix.

Step 2.2 Record: Each hunk previously assigned `hu->priv` to a protocol-
private pointer and then dereferenced it. After the patch, each callback
returns `-ENODEV` if that pointer is NULL. The affected path is receive
handling through the HCI UART line discipline, including data injected
by `TIOCSTI`.

Step 2.3 Record: Bug category is NULL pointer dereference / memory
safety. Specific mechanism: `hci_uart_tty_receive()` calls
`hu->proto->recv()`, and these callbacks dereference `hu->priv`; if
setup/error handling leaves `hu->priv` NULL, the callback crashes. The
fix adds direct NULL guards before first dereference.

Step 2.4 Record: Fix quality is high: simple, local, obviously correct,
no API/data structure changes. Regression risk is very low; it only
changes an invalid crash path to `-ENODEV`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the vulnerable lines showed the current
callback bodies come from long-standing Bluetooth UART code, with recent
edits such as `b489556a856d` for `h4_recv_buf()` usage and
`ca94b2b036c2` adding the BCSP registered guard. The vulnerable pattern
exists in `v6.19.14` and `v7.0.5`.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow.

Step 3.3 Record: Related recent commits include `0ffac654e95c` / stable
backport `981b4fd2baf3` removing the `HCI_UART_REGISTERED` guard from
`h4_recv`, and `0c3cd7a0b862` fixing a related HCI UART NULL deref in
write work. Another related upstream commit, `68d39ea5e0ad`, clears
`HCI_UART_PROTO_INIT` on register error but is present in `v7.1-rc*`,
not in checked `v6.19.14`/`v7.0.5`.

Step 3.4 Record: No prior Bluetooth commits by Aurelien DESBRIERES were
found in this checkout. The patch was committed/applied by Bluetooth
maintainer Luiz Augusto von Dentz.

Step 3.5 Record: No functional prerequisite is required for this patch
in affected trees; it applies cleanly to current `v7.0.5`. It is most
relevant to trees with the `HCI_UART_PROTO_INIT` receive path and the
recent H4 initialization-race changes, such as checked `v6.19.y` and
`v7.0.y`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 902fe40bce70` found the original thread:
`https://patch.msgid.link/20260421135331.15425-1-aurelien@hackers.camp`.
`b4 dig -a` found only v1; the committed patch matches the submitted
revision.

Step 4.2 Record: `b4 dig -w` showed recipients included `linux-
bluetooth`, Marcel Holtmann, Johan Hedberg, Luiz Dentz, `linux-kernel`,
and syzbot. The patchwork bot reported it was applied to
`bluetooth/bluetooth-next.git` by Luiz Augusto von Dentz.

Step 4.3 Record: Syzkaller bug page verifies: “general protection fault
in h4_recv”, KASAN NULL-ptr-deref, C and syz reproducers, and fix commit
`902fe40bce70`.

Step 4.4 Record: No multi-patch series was found; only v1 of this one-
patch submission.

Step 4.5 Record: Direct lore stable fetch was blocked by Anubis; web
search found no stable-specific discussion. This does not affect the
decision because the syzbot crash and code path are verified elsewhere.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified functions: `ath_recv`, `bcsp_recv`, `h4_recv`,
`h5_recv`.

Step 5.2 Record: Exact call path verified: protocol structs assign
`.recv = h4_recv/ath_recv/bcsp_recv/h5_recv`; `hci_uart_tty_receive()`
calls `hu->proto->recv(hu, data, count)`; `tiocsti()` calls the line
discipline `receive_buf`.

Step 5.3 Record: Key callees include `h4_recv_buf()`,
`hci_recv_frame()`, `h5_reset_rx()`, `bcsp_unslip_one_byte()`, and skb
cleanup helpers. The first unsafe operation in each changed function was
a dereference of the private pointer.

Step 5.4 Record: Reachability is verified from userspace ioctl in the
syzkaller trace and reproducer: `openat("/dev/ptmx")`, `TIOCSETD` to
`N_HCI`, `HCIUARTSETPROTO` with fault injection, then `TIOCSTI`.

Step 5.5 Record: Similar HCI UART receive callbacks exist; some, like
`qca_recv` and `ll_recv`, still have `HCI_UART_REGISTERED` guards before
dereferencing private data. The candidate focuses on the four callbacks
identified in the accepted patch.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v6.19.14` and `v7.0.5`: the four callbacks
exist without the new NULL checks. These trees also have
`hci_uart_tty_receive()` accepting `HCI_UART_PROTO_INIT`. Checked
`v6.6`/`v6.12`: older receive gating differs, so the exact trigger is
less clearly present there.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `v7.0.5` checkout. Expected backport difficulty for similar
affected trees is clean or trivial.

Step 6.3 Record: No equivalent recv-callback NULL guard was found in
`v6.19.14` or `v7.0.5`. A related central cleanup exists upstream as
`68d39ea5e0ad`, but not in those checked stable tags.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Bluetooth HCI UART, a driver subsystem
under `drivers/bluetooth`. Criticality: important for systems using
UART-attached Bluetooth controllers; not universal core kernel code.

Step 7.2 Record: Bluetooth UART code is actively changing in this range,
with recent initialization-race and NULL-deref fixes in the same area.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with `N_HCI` / HCI UART
Bluetooth line discipline enabled, especially with H4/H5/ATH/BCSP
protocol paths.

Step 8.2 Record: Trigger verified by syzkaller requires HCI UART line
discipline setup, fault/error during protocol setup, then received data
through `TIOCSTI`. The reproducer uses fault injection and ioctl access;
unprivileged exploitability was not established.

Step 8.3 Record: Failure mode is kernel oops/general protection fault
from KASAN NULL dereference in `h4_recv`; severity HIGH to CRITICAL
because it crashes the kernel.

Step 8.4 Record: Benefit is high for affected stable trees because it
prevents a reproducible kernel crash. Risk is very low: 12 added lines,
no new feature, no locking changes, no API changes.

## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: syzbot report with
reproducer, KASAN NULL deref, syscall-triggered path, small surgical
patch, accepted by Bluetooth maintainer, applies cleanly to checked
stable tree. Evidence against: trigger appears tied to setup
failure/fault injection and may not affect older stable trees with
different HCI UART initialization flow. Unresolved: exact applicability
to every older LTS branch was not fully verified.

Step 9.2 Record: Stable rules checklist: obviously correct: yes; fixes
real bug: yes, syzbot crash; important issue: yes, kernel oops; small
and contained: yes, 12 insertions in four driver callbacks; no new
features/APIs: yes; applies to stable: yes for checked `v7.0.5`, likely
trivial for affected `v6.19.y`.

Step 9.3 Record: No exception category needed; this is a direct crash
fix, not a device ID/quirk/build/doc patch.

Step 9.4 Record: Decision is to backport to affected stable trees,
especially those containing the `HCI_UART_PROTO_INIT` receive path and
recent HCI UART initialization fixes. The benefit/risk ratio is strongly
favorable.

## Verification
- Phase 1: Parsed commit `902fe40bce7059722f7ffa1c378e577675cf1918` with
  `git show`; verified syzbot and Closes tags.
- Phase 2: Verified diff stat: four files, 12 insertions, only NULL
  guards in recv callbacks.
- Phase 3: Ran `git blame` on changed callback lines and inspected
  related commits `0ffac654e95c`, `981b4fd2baf3`, `0c3cd7a0b862`, and
  `68d39ea5e0ad`.
- Phase 4: Ran `b4 dig -c`, `-a`, and `-w`; fetched mirror thread and
  syzkaller bug/reproducer.
- Phase 5: Verified call path with source reads and exact searches:
  `tiocsti()` -> line discipline `receive_buf` ->
  `hci_uart_tty_receive()` -> protocol `.recv`.
- Phase 6: Checked `v6.19.14`, `v7.0.5`, `v6.12`, and `v6.6` snippets;
  verified patch applies to current `v7.0.5` with `git apply --check`.
- Phase 8: Verified failure mode from syzkaller crash log: KASAN NULL-
  ptr-deref/general protection fault in `h4_recv`.
- UNVERIFIED: Exact applicability to every active older stable/LTS
  branch; older branches with different HCI UART gating may not need
  this patch.

**YES**

 drivers/bluetooth/hci_ath.c  | 3 +++
 drivers/bluetooth/hci_bcsp.c | 3 +++
 drivers/bluetooth/hci_h4.c   | 3 +++
 drivers/bluetooth/hci_h5.c   | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index fa679ad0acdfa..8201fa7f61e84 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -191,6 +191,9 @@ static int ath_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct ath_struct *ath = hu->priv;
 
+	if (!ath)
+		return -ENODEV;
+
 	ath->rx_skb = h4_recv_buf(hu, ath->rx_skb, data, count,
 				  ath_recv_pkts, ARRAY_SIZE(ath_recv_pkts));
 	if (IS_ERR(ath->rx_skb)) {
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index b386f91d8b46d..db56eead27ceb 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -585,6 +585,9 @@ static int bcsp_recv(struct hci_uart *hu, const void *data, int count)
 	if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
 		return -EUNATCH;
 
+	if (!bcsp)
+		return -ENODEV;
+
 	BT_DBG("hu %p count %d rx_state %d rx_count %ld",
 	       hu, count, bcsp->rx_state, bcsp->rx_count);
 
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index a889a66a326f7..7673727074985 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -109,6 +109,9 @@ static int h4_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct h4_struct *h4 = hu->priv;
 
+	if (!h4)
+		return -ENODEV;
+
 	h4->rx_skb = h4_recv_buf(hu, h4->rx_skb, data, count,
 				 h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
 	if (IS_ERR(h4->rx_skb)) {
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index cfdf75dc28475..d353837182125 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -587,6 +587,9 @@ static int h5_recv(struct hci_uart *hu, const void *data, int count)
 	struct h5 *h5 = hu->priv;
 	const unsigned char *ptr = data;
 
+	if (!h5)
+		return -ENODEV;
+
 	BT_DBG("%s pending %zu count %d", hu->hdev->name, h5->rx_pending,
 	       count);
 
-- 
2.53.0


^ permalink raw reply related

* RE: [BlueZ] adapter: add BCAA UUID also when seen device is not discoverable
From: bluez.test.bot @ 2026-05-11 23:08 UTC (permalink / raw)
  To: linux-bluetooth, pav
In-Reply-To: <a03d5b481c87d86d2bd2bdb376729ea6c4f992a9.1778535912.git.pav@iki.fi>

[-- Attachment #1: Type: text/plain, Size: 1478 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=1093117

---Test result---

Test Summary:
CheckPatch                    PASS      0.29 seconds
GitLint                       FAIL      0.20 seconds
BuildEll                      PASS      20.52 seconds
BluezMake                     PASS      655.94 seconds
CheckSmatch                   PASS      355.51 seconds
bluezmakeextell               PASS      183.32 seconds
IncrementalBuild              PASS      658.13 seconds
ScanBuild                     PASS      1044.68 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ] adapter: add BCAA UUID also when seen device is not discoverable

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
23: B1 Line exceeds max length (89>80): "Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2812#note_3467783"


https://github.com/bluez/bluez/pull/2119

---
Regards,
Linux Bluetooth


^ permalink raw reply

* Question: recommended way to detect re-pairing completion over D-Bus
From: Tomoka Kimura @ 2026-05-12  2:00 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

I'm developing an embedded device using BlueZ and need to update the
UI when pairing has fully completed.

For initial pairing, I can use the `PropertiesChanged` signal for
`org.bluez.Device1.Paired`, which works well.

However, during re-pairing, if the remote device deletes its pairing
information while my device keeps the existing bond, I cannot detect
when the new pairing has actually completed. In this case, the
`org.bluez.Device1` object already exists, and `Paired`/`Bonded` are
already `true`, so no `PropertiesChanged` signal is emitted.

Environment:
- BlueZ 5.72
- BR/EDR peripheral + BLE peripheral
- Agent capability: NoInputNoOutput
- `JustWorksRepairing=confirm`

What I observed:
- `RequestAuthorization` is called before LTK storage completes, so it
appears too early to treat as pairing completion
- `Connected` also becomes true too early
- `ServicesResolved` does not seem suitable because it is tied to
service discovery rather than pairing/bond persistence, and its timing
can vary depending on the device. In some cases it may be emitted
noticeably after pairing has already completed

What I need is a reliable indication that pairing/bonding has fully
completed and all keys have been stored, including during re-pairing.

My questions are:

1. Is there an official D-Bus API/signal/property for detecting this
completion point?
2. If not, what is the recommended approach for applications that need
to update UI at the correct timing?

I also checked the source up to 5.86 and it looks like
`device_set_paired()` / `device_set_bonded()` still do not emit
`PropertiesChanged` if both bearers are already paired/bonded.

Any guidance would be appreciated.

Best regards,
Tomoka Kimura

^ permalink raw reply

* [PATCH v1] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609 Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip.
From: Luke-yj Chen @ 2026-05-12  3:34 UTC (permalink / raw)
  To: Marcel Holtmann, Johan Hedberg, Luiz Von Dentz
  Cc: Sean Wang, Chris Lu, Will Lee, SS Wu, Steve Lee, linux-bluetooth,
	linux-kernel, linux-mediatek, luke-yj.chen

From: "luke-yj.chen" <luke-yj.chen@mediatek.com>

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3609 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: luke-yj.chen <luke-yj.chen@mediatek.com>
---
 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e601f9..d1581fd74035 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -789,6 +789,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3608), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x13d3, 0x3609), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
-- 
2.45.2


^ permalink raw reply related

* [PATCH v2] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609
From: Luke-yj Chen @ 2026-05-12  6:03 UTC (permalink / raw)
  To: Marcel Holtmann, Johan Hedberg, Luiz Von Dentz
  Cc: Sean Wang, Chris Lu, Will Lee, SS Wu, Steve Lee, linux-bluetooth,
	linux-kernel, linux-mediatek, luke-yj.chen

From: "luke-yj.chen" <luke-yj.chen@mediatek.com>

Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3609 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: luke-yj.chen <luke-yj.chen@mediatek.com>
---
v2: change title and commit message
---
 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e601f9..d1581fd74035 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -789,6 +789,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3608), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x13d3, 0x3609), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
-- 
2.45.2


^ permalink raw reply related

* [PATCH v1] Bluetooth: btusb: Add support for Intel Lizard Peak2 (0x8087:0x0040)
From: Ravindra @ 2026-05-12  6:20 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: ravishankar.srivatsa, kiran.k, chethan.tumkur.narayan, Ravindra

Device from /sys/kernel/debug/usb/devices:

T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0040 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Ravindra <ravindra@intel.com>
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e601f9..3f012c2a014a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },
+	{ USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak2 */
 	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
 	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
 						     BTUSB_INTEL_NO_WBS_SUPPORT |
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v1] Bluetooth: btusb: Add support for Intel Lizard Peak2 (0x8087:0x0040)
From: Paul Menzel @ 2026-05-12  6:24 UTC (permalink / raw)
  To: Ravindra
  Cc: linux-bluetooth, ravishankar.srivatsa, kiran.k,
	chethan.tumkur.narayan
In-Reply-To: <20260512062045.1213631-1-ravindra@intel.com>

Dear Ravindra,


Thank you for your patch.

(Is the spelling for Lizard Peak2 really without a space before the 2?)

Am 12.05.26 um 08:20 schrieb Ravindra:
> Device from /sys/kernel/debug/usb/devices:
> 
> T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
> D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=8087 ProdID=0040 Rev= 0.00
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> 
> Signed-off-by: Ravindra <ravindra@intel.com>
> ---
>   drivers/bluetooth/btusb.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 572091e601f9..3f012c2a014a 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {
>   	{ USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },
>   	{ USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },
>   	{ USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },
> +	{ USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak2 */
>   	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
>   	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
>   						     BTUSB_INTEL_NO_WBS_SUPPORT |

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

^ permalink raw reply

* RE: [v1] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609 Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip.
From: bluez.test.bot @ 2026-05-12  8:03 UTC (permalink / raw)
  To: linux-bluetooth, luke-yj.chen
In-Reply-To: <20260512033422.3242781-1-luke-yj.chen@mediatek.com>

[-- Attachment #1: Type: text/plain, Size: 1767 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=1093267

---Test result---

Test Summary:
CheckPatch                    PASS      0.66 seconds
GitLint                       FAIL      0.33 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      25.18 seconds
CheckAllWarning               PASS      27.95 seconds
CheckSparse                   PASS      26.49 seconds
BuildKernel32                 PASS      25.11 seconds
TestRunnerSetup               PASS      522.03 seconds
IncrementalBuild              PASS      23.44 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v1] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609 Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip.

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (116>80): "[v1] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609 Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip."
1: T3 Title has trailing punctuation (.): "[v1] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609 Add VID 13d3 & PID 3609 for MediaTek MT7925 USB Bluetooth chip."


https://github.com/bluez/bluetooth-next/pull/174

---
Regards,
Linux Bluetooth


^ permalink raw reply

* RE: [v1] Bluetooth: btusb: Add support for Intel Lizard Peak2 (0x8087:0x0040)
From: bluez.test.bot @ 2026-05-12  8:03 UTC (permalink / raw)
  To: linux-bluetooth, ravindra
In-Reply-To: <20260512062045.1213631-1-ravindra@intel.com>

[-- Attachment #1: Type: text/plain, Size: 882 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=1093290

---Test result---

Test Summary:
CheckPatch                    PASS      0.53 seconds
GitLint                       PASS      0.20 seconds
SubjectPrefix                 PASS      0.06 seconds
BuildKernel                   PASS      26.54 seconds
CheckAllWarning               PASS      29.03 seconds
CheckSparse                   PASS      27.30 seconds
BuildKernel32                 PASS      25.44 seconds
TestRunnerSetup               PASS      569.49 seconds
IncrementalBuild              PASS      24.94 seconds



https://github.com/bluez/bluetooth-next/pull/176

---
Regards,
Linux Bluetooth


^ permalink raw reply

* RE: [v2] Bluetooth: btusb: MT7925: Add VID/PID 13d3/3609
From: bluez.test.bot @ 2026-05-12  8:04 UTC (permalink / raw)
  To: linux-bluetooth, luke-yj.chen
In-Reply-To: <20260512060318.3288273-1-luke-yj.chen@mediatek.com>

[-- Attachment #1: Type: text/plain, Size: 882 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=1093276

---Test result---

Test Summary:
CheckPatch                    PASS      1.32 seconds
GitLint                       PASS      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      27.01 seconds
CheckAllWarning               PASS      29.57 seconds
CheckSparse                   PASS      28.09 seconds
BuildKernel32                 PASS      26.52 seconds
TestRunnerSetup               PASS      588.49 seconds
IncrementalBuild              PASS      25.67 seconds



https://github.com/bluez/bluetooth-next/pull/175

---
Regards,
Linux Bluetooth


^ permalink raw reply

* [PATCH v2] Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
From: Ravindra @ 2026-05-12  8:22 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: ravishankar.srivatsa, kiran.k, chethan.tumkur.narayan, Ravindra

Device from /sys/kernel/debug/usb/devices:

T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0040 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Ravindra <ravindra@intel.com>
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e601f9..3f012c2a014a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },
+	{ USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak2 */
 	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
 	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
 						     BTUSB_INTEL_NO_WBS_SUPPORT |
-- 
2.43.0


^ permalink raw reply related

* [PATCH v3] Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
From: Ravindra @ 2026-05-12  8:34 UTC (permalink / raw)
  To: linux-bluetooth
  Cc: ravishankar.srivatsa, kiran.k, chethan.tumkur.narayan, Ravindra

Device from /sys/kernel/debug/usb/devices:

T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0040 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Ravindra <ravindra@intel.com>
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e601f9..26f45bcf9f11 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },
 	{ USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },
+	{ USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak 2 */
 	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
 	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
 						     BTUSB_INTEL_NO_WBS_SUPPORT |
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v2] Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
From: Paul Menzel @ 2026-05-12  8:36 UTC (permalink / raw)
  To: Ravindra
  Cc: linux-bluetooth, ravishankar.srivatsa, kiran.k,
	chethan.tumkur.narayan
In-Reply-To: <20260512082256.1214764-1-ravindra@intel.com>

Dear Ravindra,


Thank you for your patch.

Am 12.05.26 um 10:22 schrieb Ravindra:
> Device from /sys/kernel/debug/usb/devices:
> 
> T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
> D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=8087 ProdID=0040 Rev= 0.00
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
> 
> Signed-off-by: Ravindra <ravindra@intel.com>
> ---
>   drivers/bluetooth/btusb.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 572091e601f9..3f012c2a014a 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {
>   	{ USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },
>   	{ USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },
>   	{ USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },
> +	{ USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak2 */
>   	{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
>   	{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
>   						     BTUSB_INTEL_NO_WBS_SUPPORT |

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

^ permalink raw reply

* [PATCH BlueZ] pbap: Fix not checking Database Identifier length
From: Frédéric Danis @ 2026-05-12  8:37 UTC (permalink / raw)
  To: linux-bluetooth

Database Identifier is supposed to be 16 bytes values.

A paired Bluetooth device acting as a PBAP server can overflow the
heap in obexd by up to 239 bytes into adjacent allocations by returning
a DATABASEID_TAG application parameter with an oversized length.
With both length and content fully attacker-controlled, this enables
standard glibc heap exploitation primitives (tcache/fastbin poisoning)
leading to remote code execution in the obexd process.
---
 obexd/client/pbap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/obexd/client/pbap.c b/obexd/client/pbap.c
index 0f575e61e..ce5e6cd5d 100644
--- a/obexd/client/pbap.c
+++ b/obexd/client/pbap.c
@@ -330,7 +330,8 @@ static void read_databaseid(struct pbap_data *pbap, GObexApparam *apparam)
 		data = value;
 	}
 
-	if (memcmp(data, pbap->databaseid, len)) {
+	if (len == sizeof(pbap->databaseid) &&
+			memcmp(data, pbap->databaseid, len)) {
 		memcpy(pbap->databaseid, data, len);
 		g_dbus_emit_property_changed(conn,
 					obc_session_get_path(pbap->session),
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v1] Bluetooth: btusb: Add support for Intel Lizard Peak2 (0x8087:0x0040)
From: Ravindra @ 2026-05-12  8:39 UTC (permalink / raw)
  To: Paul Menzel
  Cc: linux-bluetooth@vger.kernel.org, Srivatsa, Ravishankar, K, Kiran,
	Tumkur Narayan, Chethan
In-Reply-To: <33bfcf77-2709-4b5d-a932-ed2987c6410f@molgen.mpg.de>






________________________________________
From: Paul Menzel <pmenzel@molgen.mpg.de>
Sent: Tuesday, May 12, 2026 11:54 AM
To: Ravindra <ravindra@intel.com>
Cc: linux-bluetooth@vger.kernel.org <linux-bluetooth@vger.kernel.org>; Srivatsa, Ravishankar <ravishankar.srivatsa@intel.com>; K, Kiran <kiran.k@intel.com>; Tumkur Narayan, Chethan <chethan.tumkur.narayan@intel.com>
Subject: Re: [PATCH v1] Bluetooth: btusb: Add support for Intel Lizard Peak2 (0x8087:0x0040)


Dear Ravindra,





Thank you for your patch.



(Is the spelling for Lizard Peak2 really without a space before the 2?)
Yes, that is correct. According to the hardware specification and the firmware strings, "Lizard Peak 2" is written as a single word with a space.



Am 12.05.26 um 08:20 schrieb Ravindra:

> Device from /sys/kernel/debug/usb/devices:

>

> T:  Bus=09 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0

> D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1

> P:  Vendor=8087 ProdID=0040 Rev= 0.00

> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA

> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms

> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms

> I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms

> I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms

> I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms

> I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms

> I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms

> I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

> E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms

> E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

>

> Signed-off-by: Ravindra <ravindra@intel.com>

> ---

>   drivers/bluetooth/btusb.c | 1 +

>   1 file changed, 1 insertion(+)

>

> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c

> index 572091e601f9..3f012c2a014a 100644

> --- a/drivers/bluetooth/btusb.c

> +++ b/drivers/bluetooth/btusb.c

> @@ -484,6 +484,7 @@ static const struct usb_device_id quirks_table[] = {

>        { USB_DEVICE(0x8087, 0x0037), .driver_info = BTUSB_INTEL_COMBINED },

>        { USB_DEVICE(0x8087, 0x0038), .driver_info = BTUSB_INTEL_COMBINED },

>        { USB_DEVICE(0x8087, 0x0039), .driver_info = BTUSB_INTEL_COMBINED },

> +     { USB_DEVICE(0x8087, 0x0040), .driver_info = BTUSB_INTEL_COMBINED }, /* Lizard Peak2 */

>        { USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },

>        { USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |

>                                                     BTUSB_INTEL_NO_WBS_SUPPORT |



Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>





Kind regards,



Paul


^ permalink raw reply

* [bluez/bluez] 88b4a6: pbap: Fix not checking Database Identifier length
From: fdanis-oss @ 2026-05-12  9:22 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1093372
  Home:   https://github.com/bluez/bluez
  Commit: 88b4a67b600e6fe2427c69629af229d292ae6076
      https://github.com/bluez/bluez/commit/88b4a67b600e6fe2427c69629af229d292ae6076
  Author: Frédéric Danis <frederic.danis@collabora.com>
  Date:   2026-05-12 (Tue, 12 May 2026)

  Changed paths:
    M obexd/client/pbap.c

  Log Message:
  -----------
  pbap: Fix not checking Database Identifier length

Database Identifier is supposed to be 16 bytes values.

A paired Bluetooth device acting as a PBAP server can overflow the
heap in obexd by up to 239 bytes into adjacent allocations by returning
a DATABASEID_TAG application parameter with an oversized length.
With both length and content fully attacker-controlled, this enables
standard glibc heap exploitation primitives (tcache/fastbin poisoning)
leading to remote code execution in the obexd process.



To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox