* Re: [PATCH BlueZ v2] adapter: Infer BR/EDR only at public LE addresses
From: patchwork-bot+bluetooth @ 2026-07-20 19:40 UTC (permalink / raw)
To: Philipp Dunkel; +Cc: linux-bluetooth
In-Reply-To: <20260717082347.8429-1-pip@pipobscure.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Fri, 17 Jul 2026 10:23:47 +0200 you wrote:
> btd_adapter_device_found() records BR/EDR support for any LE device
> whose advertising Flags lack "BR/EDR Not Supported" (EIR_BREDR_UNSUP).
> The address type is not considered:
>
> if (bdaddr_type != BDADDR_BREDR && eir_data.flags &&
> !(eir_data.flags & EIR_BREDR_UNSUP)) {
> device_set_bredr_support(dev);
>
> [...]
Here is the summary with links:
- [BlueZ,v2] adapter: Infer BR/EDR only at public LE addresses
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=9965f36c6318
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] policy: Connect profiles for bonded inbound ACL connections
From: patchwork-bot+bluetooth @ 2026-07-20 19:40 UTC (permalink / raw)
To: Chengyi Zhao; +Cc: linux-bluetooth, luiz.von.dentz, marcel, zhaochengyi
In-Reply-To: <tencent_7E6A07CE6162892EDEFA29E082F2D2A8AE05@qq.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 16 Jul 2026 18:55:03 +0800 you wrote:
> From: Chengyi Zhao <zhaochengyi@uniontech.com>
>
> When a bonded device initiates an inbound ACL connection (e.g. after
> resume, the remote wins the page race), BlueZ accepts the ACL link
> but does not establish AVDTP/AVCTP profiles. The remote's subsequent
> L2CAP connect for PSM 25 fails with "security block" because the link
> is not yet encrypted, and the kernel does not retry. The ACL link
> stays up with no audio.
>
> [...]
Here is the summary with links:
- [BlueZ] policy: Connect profiles for bonded inbound ACL connections
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=f3f03d728542
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] adapter: restrict delta=0 RSSI to proximity filters
From: patchwork-bot+bluetooth @ 2026-07-20 19:40 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: luiz.dentz, linux-bluetooth, cheng.jiang, quic_chezhou, wei.deng,
shuai.zhang, mengshi.wu, jinwang.li
In-Reply-To: <20260715091936.4137598-1-xiuzhuo.shang@oss.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 15 Jul 2026 17:19:36 +0800 you wrote:
> When a discovery filter is active (filtered_discovery=true), BlueZ
> unconditionally calls device_set_rssi_with_delta(..., delta=0),
> causing every BLE advertisement to emit a PropertiesChanged(RSSI)
> signal regardless of whether the RSSI value changed.
>
> delta=0 is only needed when a client has expressed explicit proximity
> interest by setting an RSSI or pathloss threshold in its discovery
> filter. Filters that specify only transport type or UUIDs do not
> require per-packet RSSI precision; for those, the standard
> RSSI_THRESHOLD=8 rate-limiting is both correct and desirable.
>
> [...]
Here is the summary with links:
- adapter: restrict delta=0 RSSI to proximity filters
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e004414a1751
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] test-runner: use virtio for the default kernel console
From: patchwork-bot+bluetooth @ 2026-07-20 19:40 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <e71384747c71a2fa0db585acdb727f324161d1b8.1784554811.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 Mon, 20 Jul 2026 17:09:01 +0300 you wrote:
> Serial as console is slow when commands produce large amounts of output,
> e.g. for the -d debug option of the testers.
>
> Use virtio console=hvc0 as the console, requiring
> CONFIG_VIRTIO_CONSOLE=y which is already in tester config.
>
> For capturing the early boot messages, retain the qemu serial, kernel
> will switch to hvc0 during boot when the HVC driver initializes.
>
> [...]
Here is the summary with links:
- [BlueZ] test-runner: use virtio for the default kernel console
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=004e1b5d245e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: Re: [PATCH v2] Bluetooth: HIDP: add missing length check for incoming frames
From: Luiz Augusto von Dentz @ 2026-07-20 19:47 UTC (permalink / raw)
To: jiale yao
Cc: Marcel Holtmann, Tim Bird, Muhammad Bilal, Kees Cook,
Michael Bommarito, linux-bluetooth, linux-kernel
In-Reply-To: <220b6be5.d3f.19f78e165aa.Coremail.19888972804@163.com>
Hi,
On Sun, Jul 19, 2026 at 1:38 AM jiale yao <19888972804@163.com> wrote:
>
>
>
>
>
>
>
> In hidp_recv_ctrl_frame() and hidp_recv_intr_frame(), skb->data[0] is
> read without verifying that skb->len >= 1. A zero-length L2CAP PDU
> delivered via the HIDP control or interrupt channel causes an
> out-of-bounds read.
>
> Use skb_pull_data(skb, 1) which combines the length check and pull
> in one operation, matching the existing pattern in hidp_input_report()
> and the fix in commit 6770d3a8acdf ("Bluetooth: bnep: reject short
> frames before parsing") which addressed the same class of bug in BNEP.
>
> Assisted-by: Claude:deepseek-v4-pro
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
> net/bluetooth/hidp/core.c | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 0e24c5e2955e..bb61602b02e1 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -560,16 +560,18 @@ static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> static void hidp_recv_ctrl_frame(struct hidp_session *session,
> struct sk_buff *skb)
> {
> - unsigned char hdr, type, param;
> + unsigned char *hdr;
> + unsigned char type, param;
> int free_skb = 1;
>
> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>
> - hdr = skb->data[0];
> - skb_pull(skb, 1);
> + hdr = skb_pull_data(skb, 1);
> + if (!hdr)
> + return;
https://sashiko.dev/#/patchset/20260717153238.2002330-1-yaojiale02%40163.com
It seems that by early returning we are leaking the skb.
>
> - type = hdr & HIDP_HEADER_TRANS_MASK;
> - param = hdr & HIDP_HEADER_PARAM_MASK;
> + type = *hdr & HIDP_HEADER_TRANS_MASK;
> + param = *hdr & HIDP_HEADER_PARAM_MASK;
>
> switch (type) {
> case HIDP_TRANS_HANDSHAKE:
> @@ -597,14 +599,15 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> static void hidp_recv_intr_frame(struct hidp_session *session,
> struct sk_buff *skb)
> {
> - unsigned char hdr;
> + unsigned char *hdr;
>
> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
>
> - hdr = skb->data[0];
> - skb_pull(skb, 1);
> + hdr = skb_pull_data(skb, 1);
> + if (!hdr)
> + return;
>
> - if (hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
> + if (*hdr == (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_INPUT)) {
> hidp_set_timer(session);
>
> if (session->input)
> --
> 2.34.1
>
>
>
>
>
>
>
>
>
>
>
>
> At 2026-07-17 23:40:11, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
> >Hi,
> >
> >On Fri, Jul 17, 2026 at 11:33 AM Jiale Yao <yaojiale02@163.com> wrote:
> >>
> >> In hidp_recv_ctrl_frame() and hidp_recv_intr_frame(), skb->data[0] is
> >> read without verifying that skb->len >= 1. A zero-length L2CAP PDU
> >> delivered via the HIDP control or interrupt channel causes an
> >> out-of-bounds read.
> >>
> >> Add pskb_may_pull(skb, 1) guards before both reads, matching the fix
> >> in commit 6770d3a8acdf ("Bluetooth: bnep: reject short frames before
> >> parsing") which addressed the same class of bug in BNEP.
> >>
> >> Assisted-by: Claude:deepseek-v4-pro
> >> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> >> ---
> >> net/bluetooth/hidp/core.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> >> index 0e24c5e2955e..6c7da8aca732 100644
> >> --- a/net/bluetooth/hidp/core.c
> >> +++ b/net/bluetooth/hidp/core.c
> >> @@ -565,6 +565,8 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> >>
> >> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
> >>
> >> + if (!pskb_may_pull(skb, 1))
> >> + return;
> >
> >We can probably replace this with skb_pull_data.
> >
> >> hdr = skb->data[0];
> >> skb_pull(skb, 1);
> >>
> >> @@ -601,6 +603,8 @@ static void hidp_recv_intr_frame(struct hidp_session *session,
> >>
> >> BT_DBG("session %p skb %p len %u", session, skb, skb->len);
> >>
> >> + if (!pskb_may_pull(skb, 1))
> >> + return;
> >
> >Ditto.
> >
> >> hdr = skb->data[0];
> >> skb_pull(skb, 1);
> >>
> >> --
> >> 2.34.1
> >>
> >
> >
> >--
> >Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix BT dependency for submodules
From: Luiz Augusto von Dentz @ 2026-07-20 19:50 UTC (permalink / raw)
To: Iva Kasprzaková; +Cc: marcel, linux-bluetooth, xrabek1, xkasprz
In-Reply-To: <20260720150919.9602-1-iva@yenya.net>
Hi Iva,
On Mon, Jul 20, 2026 at 11:09 AM Iva Kasprzaková <iva@yenya.net> wrote:
>
> Rfcomm (BT_RFCOMM), bnep (BT_BNEP), and hidp (BT_HIDP) modules are
> dependent on the bluetooth module (BT, tristate) only transitively
> through the boolean BT_BREDR. Therefore, the modules can be selected as
> built-in even if the BT=m. The combination of BT=m and =y for the said
> modules leads to the kernel build system silently ignoring those
> modules, without ever compiling them as built-in or as loadable modules.
>
> Add BT as a direct dependency to Kconfig of rfcomm, bnep and hidp. The
> modules set to =y when BT=m will default to =m, rather then getting
> silently ignored by the build system.
>
> Signed-off-by: Iva Kasprzaková <iva@yenya.net>
> ---
> net/bluetooth/bnep/Kconfig | 2 +-
> net/bluetooth/hidp/Kconfig | 2 +-
> net/bluetooth/rfcomm/Kconfig | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/bnep/Kconfig b/net/bluetooth/bnep/Kconfig
> index aac02b5b0d17..f8087e2d2c00 100644
> --- a/net/bluetooth/bnep/Kconfig
> +++ b/net/bluetooth/bnep/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config BT_BNEP
> tristate "BNEP protocol support"
> - depends on BT_BREDR
> + depends on BT && BT_BREDR
> select CRC32
> help
> BNEP (Bluetooth Network Encapsulation Protocol) is Ethernet
> diff --git a/net/bluetooth/hidp/Kconfig b/net/bluetooth/hidp/Kconfig
> index e08aae35351a..ba52c7296f18 100644
> --- a/net/bluetooth/hidp/Kconfig
> +++ b/net/bluetooth/hidp/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config BT_HIDP
> tristate "HIDP protocol support"
> - depends on BT_BREDR && HID
> + depends on BT && BT_BREDR && HID
> help
> HIDP (Human Interface Device Protocol) is a transport layer
> for HID reports. HIDP is required for the Bluetooth Human
> diff --git a/net/bluetooth/rfcomm/Kconfig b/net/bluetooth/rfcomm/Kconfig
> index 9b9953ebf4c0..e7af2d565cea 100644
> --- a/net/bluetooth/rfcomm/Kconfig
> +++ b/net/bluetooth/rfcomm/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config BT_RFCOMM
> tristate "RFCOMM protocol support"
> - depends on BT_BREDR
> + depends on BT && BT_BREDR
> help
> RFCOMM provides connection oriented stream transport. RFCOMM
> support is required for Dialup Networking, OBEX and other Bluetooth
>
> base-commit: c1cec2bbbeb5922d42d28c6af1707c4f3f8647e3
> --
> 2.55.0
Looks like BT_6LOWPAN could also use the same logic:
https://sashiko.dev/#/patchset/20260720150919.9602-1-iva%40yenya.net
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_sync: Fix scan response data UAF
From: Luiz Augusto von Dentz @ 2026-07-20 19:54 UTC (permalink / raw)
To: Chengfeng Ye; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, stable
In-Reply-To: <20260720164738.2921802-1-nicoyip.dev@gmail.com>
Hi,
On Mon, Jul 20, 2026 at 12:47 PM Chengfeng Ye <nicoyip.dev@gmail.com> wrote:
>
> eir_create_scan_rsp() calls hci_find_adv_instance(), whose return value is
> valid only while hdev->lock is held. After advertising setup was moved to
> hci_cmd_sync_work, neither scan response data builder held that lock.
> hci_set_ext_scan_rsp_data_sync() also kept the returned pointer while
> waiting for the controller and wrote scan_rsp_changed through it afterward.
>
> An advertising termination event can therefore interleave as follows:
>
> hci_cmd_sync_work hci_rx_work
> hci_find_adv_instance()
> __hci_cmd_sync_status()
> wait for controller reply hci_dev_lock()
> hci_remove_adv_instance()
> kfree(adv)
> adv->scan_rsp_changed = false
>
> KASAN reported:
>
> BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300
> Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88
> Workqueue: hci0 hci_cmd_sync_work
> Call Trace:
> hci_set_ext_scan_rsp_data_sync+0x2e1/0x300
> hci_schedule_adv_instance_sync+0x390/0x4c0
> hci_cmd_sync_work+0x173/0x300
> Allocated by task 87:
> hci_add_adv_instance+0x538/0xac0
> add_advertising+0x885/0x1160
> Freed by task 89:
> kfree+0x131/0x3c0
> hci_remove_adv_instance+0x1d8/0x3b0
> hci_le_ext_adv_term_evt+0x17b/0x730
>
> Hold hdev->lock while looking up the instance, building the scan
> response, and clearing its dirty bit. Clear the bit before waiting for
> the controller so no adv_info pointer survives the wait, and restore it
> under the lock if the command fails. This also preserves an update that
> races with a successful command because that update sets the bit again.
> Protect the legacy scan response builder with the same lock.
>
> Fixes: cba6b758711c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
> ---
> net/bluetooth/hci_sync.c | 32 +++++++++++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index 532534bc601c..8c69a98c71e8 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -1490,9 +1490,13 @@ static int hci_set_ext_scan_rsp_data_sync(struct hci_dev *hdev, u8 instance)
> int err;
>
> if (instance) {
> + hci_dev_lock(hdev);
> +
> adv = hci_find_adv_instance(hdev, instance);
> - if (!adv || !adv->scan_rsp_changed)
> + if (!adv || !adv->scan_rsp_changed) {
> + hci_dev_unlock(hdev);
> return 0;
> + }
> }
>
> len = eir_create_scan_rsp(hdev, instance, pdu->data);
> @@ -1502,15 +1506,27 @@ static int hci_set_ext_scan_rsp_data_sync(struct hci_dev *hdev, u8 instance)
> pdu->operation = LE_SET_ADV_DATA_OP_COMPLETE;
> pdu->frag_pref = LE_SET_ADV_DATA_NO_FRAG;
>
> + if (adv) {
> + adv->scan_rsp_changed = false;
> + hci_dev_unlock(hdev);
> + }
> +
> err = __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_EXT_SCAN_RSP_DATA,
> struct_size(pdu, data, len), pdu,
> HCI_CMD_TIMEOUT);
> - if (err)
> + if (err) {
> + if (instance) {
> + hci_dev_lock(hdev);
> + adv = hci_find_adv_instance(hdev, instance);
> + if (adv)
> + adv->scan_rsp_changed = true;
> + hci_dev_unlock(hdev);
> + }
> +
> return err;
> + }
>
> - if (adv) {
> - adv->scan_rsp_changed = false;
> - } else {
> + if (!instance) {
> memcpy(hdev->scan_rsp_data, pdu->data, len);
> hdev->scan_rsp_data_len = len;
> }
> @@ -1525,8 +1541,14 @@ static int __hci_set_scan_rsp_data_sync(struct hci_dev *hdev, u8 instance)
>
> memset(&cp, 0, sizeof(cp));
>
> + if (instance)
> + hci_dev_lock(hdev);
> +
> len = eir_create_scan_rsp(hdev, instance, cp.data);
>
> + if (instance)
> + hci_dev_unlock(hdev);
> +
> if (hdev->scan_rsp_data_len == len &&
> !memcmp(cp.data, hdev->scan_rsp_data, len))
> return 0;
> --
> 2.43.0
It looks like Sashiko found some other places where this could be a problem:
https://sashiko.dev/#/patchset/20260720164738.2921802-1-nicoyip.dev%40gmail.com
--
Luiz Augusto von Dentz
^ permalink raw reply
* [bluez/bluez] e00441: adapter: restrict delta=0 RSSI to proximity filters
From: uos-eng @ 2026-07-20 19:56 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: e004414a1751d29216ccab976d6c7174ec48d11c
https://github.com/bluez/bluez/commit/e004414a1751d29216ccab976d6c7174ec48d11c
Author: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: restrict delta=0 RSSI to proximity filters
When a discovery filter is active (filtered_discovery=true), BlueZ
unconditionally calls device_set_rssi_with_delta(..., delta=0),
causing every BLE advertisement to emit a PropertiesChanged(RSSI)
signal regardless of whether the RSSI value changed.
delta=0 is only needed when a client has expressed explicit proximity
interest by setting an RSSI or pathloss threshold in its discovery
filter. Filters that specify only transport type or UUIDs do not
require per-packet RSSI precision; for those, the standard
RSSI_THRESHOLD=8 rate-limiting is both correct and desirable.
The problem is triggered on dual-mode adapters by a transport-only
filter (e.g. Transport=le). In merge_discovery_filters(), the
transport-specific scan type (SCAN_TYPE_LE=6) does not equal the
adapter scan type (SCAN_TYPE_DUAL=7), so has_filtered_discovery is
set, filtered_discovery becomes true, and delta=0 is applied even
though no proximity condition was requested. With hundreds of BLE
devices advertising simultaneously this generates hundreds of
unnecessary PropertiesChanged(RSSI) signals per second.
Confirmed on QCS6490 (BlueZ 5.72) with Transport=le filter:
adapter.c: filtered_discovery=1 (current_discovery_filter=set)
device.c: device_set_rssi_with_delta() rssi=-86 delta_threshold=0
device.c: device_set_rssi_with_delta() rssi=-79 delta_threshold=0
Add discovery_filter_has_proximity() which walks discovery_list and
returns true only when at least one active filter carries a real
proximity condition (rssi != DISTANCE_VAL_INVALID or pathloss !=
DISTANCE_VAL_INVALID). Use this to gate the delta=0 path.
Other filter fields (transport, uuids, duplicate, discoverable)
express capability or content criteria and carry no proximity
implication, so they are intentionally excluded from the check.
Commit: 004e1b5d245e2c3497780ab60b728cd0a9c14cf7
https://github.com/bluez/bluez/commit/004e1b5d245e2c3497780ab60b728cd0a9c14cf7
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M tools/test-runner.c
Log Message:
-----------
test-runner: use virtio for the default kernel console
Serial as console is slow when commands produce large amounts of output,
e.g. for the -d debug option of the testers.
Use virtio console=hvc0 as the console, requiring
CONFIG_VIRTIO_CONSOLE=y which is already in tester config.
For capturing the early boot messages, retain the qemu serial, kernel
will switch to hvc0 during boot when the HVC driver initializes.
For: time tools/test-runner -k ../../linux -- tools/sco-tester -d
Before: real 0m32,094s, After: real 0m8,967s
Commit: 9965f36c6318e3a6f9879f5b0d842791a290e3ee
https://github.com/bluez/bluez/commit/9965f36c6318e3a6f9879f5b0d842791a290e3ee
Author: Philipp Dunkel <pip@pipobscure.com>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: Infer BR/EDR only at public LE addresses
btd_adapter_device_found() records BR/EDR support for any LE device
whose advertising Flags lack "BR/EDR Not Supported" (EIR_BREDR_UNSUP).
The address type is not considered:
if (bdaddr_type != BDADDR_BREDR && eir_data.flags &&
!(eir_data.flags & EIR_BREDR_UNSUP)) {
device_set_bredr_support(dev);
When the advertisement uses a random address the device gets a BR/EDR
bearer whose address is that random address, and start_discovery_cb()
then prefers SDP over GATT:
if (device->bredr)
device_browse_sdp(device, NULL);
else
device_browse_gatt(device, NULL);
SDP requires a BR/EDR ACL, so bluetoothd pages the random address. A
random address is not a BD_ADDR and cannot be paged, so the attempt
always ends in Page Timeout, and the failure tears down the working LE
link:
connect_failed_callback() hci0 5A:B4:98:1F:CC:04 status 4
bonding_attempt_complete() hci0 bdaddr 5A:B4:98:1F:CC:04
type 0 status 0x4
device_bonding_complete() bonding (nil) status 0x04
browse_request_cancel()
btd_gatt_database_att_disconnected()
Nothing requested the connection ("bonding (nil)") and the LE link was
healthy. Any LE association that outlives the page timeout is killed by
it; measured on one host, applications get about 4.7 s from connect
before the link disappears, of which GATT discovery already takes 2.3 s.
Current phones advertise Flags 0x1a (LE General Discoverable plus
Simultaneous LE and BR/EDR, with BR/EDR Not Supported clear) from
resolvable private addresses, so this triggers routinely rather than in
some corner case.
The Flags bits describe what the device supports. They do not promise
that the address it is advertising from is a BD_ADDR. A dual-mode device
uses the same Public Device Address for BR/EDR and LE, so the inference
is sound only for BDADDR_LE_PUBLIC. Restrict it to that.
The other two device_set_bredr_support() callers already require the
device to have been seen over BR/EDR (bdaddr_type == BDADDR_BREDR), so
they are unaffected. A device later seen over BR/EDR, or whose RPA is
resolved to a public identity, still gets BR/EDR support recorded there.
Commit: f3f03d728542f76599385cf82348ba4f87264dcc
https://github.com/bluez/bluez/commit/f3f03d728542f76599385cf82348ba4f87264dcc
Author: Chengyi Zhao <zhaochengyi@uniontech.com>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M plugins/policy.c
M src/adapter.c
M src/adapter.h
Log Message:
-----------
policy: Connect profiles for bonded inbound ACL connections
When a bonded device initiates an inbound ACL connection (e.g. after
resume, the remote wins the page race), BlueZ accepts the ACL link
but does not establish AVDTP/AVCTP profiles. The remote's subsequent
L2CAP connect for PSM 25 fails with "security block" because the link
is not yet encrypted, and the kernel does not retry. The ACL link
stays up with no audio.
Add btd_connect_cb callback infrastructure to the adapter core
mirroring the existing btd_disconnect_cb pattern, invoked from
connected_callback so it only fires on new MGMT_EV_DEVICE_CONNECTED
events. Register a callback in the policy plugin that starts a
2-second grace timer for bonded BR/EDR connections. If an audio
profile connects naturally within the window the timer is cancelled;
otherwise btd_device_connect_services is called as a fallback, but
only if no audio profile is connected yet. The grace timer is also
cancelled on disconnect to avoid racing with device removal.
Outbound L2CAP is queued by the kernel until encryption completes,
surviving the race. The fallback is safe when the host already won
since btd_device_connect_services returns -EBUSY if a connection is
already in progress.
Compare: https://github.com/bluez/bluez/compare/efd216fe280b...f3f03d728542
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 75f75e: tools/iso-tester: fix GIOChannel refcounting
From: Pauli Virtanen @ 2026-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1131086
Home: https://github.com/bluez/bluez
Commit: 75f75eed2d13f5f981d0c24cffaf11fa494c2f3c
https://github.com/bluez/bluez/commit/75f75eed2d13f5f981d0c24cffaf11fa494c2f3c
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M tools/iso-tester.c
Log Message:
-----------
tools/iso-tester: fix GIOChannel refcounting
iso_defer_accept_* consume the reference passed in. g_io_add_watch gets
a reference.
Fix the refcounting accordingly. Also clear data->io_queue immediately
after the test, so the sockets get closed.
Not leaking references makes "ISO Connect Close - Success" to work
correctly again, exposing a KASAN crash in current kernel.
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1130938
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1129413
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1128757
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1128034
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114243
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-07-20 19:57 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114241
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 v2] Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v1()
From: Luiz Augusto von Dentz @ 2026-07-20 19:58 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: Marcel Holtmann, Amitkumar Karwar, Neeraj Kale, Paul Menzel,
linux-bluetooth, linux-kernel, stable
In-Reply-To: <20260720191322.14432-1-doruk@0sec.ai>
Hi Doruk,
On Mon, Jul 20, 2026 at 3:13 PM Doruk Tan Ozturk <doruk@0sec.ai> wrote:
>
> Commit 25c286d75821 ("Bluetooth: btnxpuart: Fix out-of-bounds firmware
> read in nxp_recv_fw_req_v3()") bounded the v3 firmware download offset but
> left an unbounded read in the v1 handler.
>
> nxp_recv_fw_req_v1() advances a device-driven download offset
> (fw_dnld_v1_offset) by fw_v1_sent_bytes on every request, and that
> bookkeeping runs even when the payload write is skipped, so the offset can
> walk past nxpdev->fw->size. When the controller then requests a header
> (len == HDR_LEN), the driver reads the 16-byte bootloader header at
>
> nxp_get_data_len(nxpdev->fw->data + nxpdev->fw_dnld_v1_offset)
>
> with no bound on the offset, reading past the end of the firmware image.
> A malicious or malfunctioning NXP UART controller can drive this to read
> out-of-bounds kernel memory during firmware download.
>
> Bound the offset before the header read, and convert the payload write
> guard to the overflow-safe form used by the v3 path (fw_dnld_v1_offset is
> u32, so fw_dnld_v1_offset + len can wrap). Log the offset, expected length
> and firmware size at the reject site to aid debugging of a real device.
>
> This was found by 0sec automated security-research tooling
> (https://0sec.ai).
>
> Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets")
> Cc: stable@vger.kernel.org
> Reviewed-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> Assisted-by: 0sec:claude-opus-4-8
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> v2: log offset/expected_len/fw size at the reject site (requested by
> Neeraj Kale and Paul Menzel). No functional change to the bound
> itself vs v1.
>
> v1: https://lore.kernel.org/linux-bluetooth/20260705115650.81724-1-doruk@0sec.ai/
> drivers/bluetooth/btnxpuart.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index 0bb300eef157..6d62d07a542b 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -1041,11 +1041,19 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev, struct sk_buff *skb)
> * and we need to re-send the previous header again.
> */
> if (len == nxpdev->fw_v1_expected_len) {
> - if (len == HDR_LEN)
> + if (len == HDR_LEN) {
> + if (nxpdev->fw_dnld_v1_offset >= nxpdev->fw->size ||
> + nxpdev->fw->size - nxpdev->fw_dnld_v1_offset < HDR_LEN) {
> + bt_dev_err(hdev, "FW request out of bounds: offset %u, expected_len %u, fw size %zu",
We still have the 80 columns limit in Bluetooth.
> + nxpdev->fw_dnld_v1_offset, len,
> + nxpdev->fw->size);
> + goto free_skb;
> + }
> nxpdev->fw_v1_expected_len = nxp_get_data_len(nxpdev->fw->data +
> nxpdev->fw_dnld_v1_offset);
> - else
> + } else {
> nxpdev->fw_v1_expected_len = HDR_LEN;
> + }
> } else if (len == HDR_LEN) {
> /* FW download out of sync. Send previous chunk again */
> nxpdev->fw_dnld_v1_offset -= nxpdev->fw_v1_sent_bytes;
> @@ -1053,7 +1061,8 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev, struct sk_buff *skb)
> }
> }
>
> - if (nxpdev->fw_dnld_v1_offset + len <= nxpdev->fw->size)
> + if (nxpdev->fw_dnld_v1_offset < nxpdev->fw->size &&
> + len <= nxpdev->fw->size - nxpdev->fw_dnld_v1_offset)
> serdev_device_write_buf(nxpdev->serdev, nxpdev->fw->data +
> nxpdev->fw_dnld_v1_offset, len);
> nxpdev->fw_v1_sent_bytes = len;
> --
> 2.43.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: Pauli Virtanen @ 2026-07-20 20:08 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, marcel, iulia.tanasescu, linux-kernel
In-Reply-To: <CABBYNZKtXwpnz9PH3eR31ETKAvPOoCnWebKf0UUDpe7tPQs3Kg@mail.gmail.com>
Hi Luiz,
ma, 2026-07-20 kello 15:37 -0400, Luiz Augusto von Dentz kirjoitti:
> Hi Pauli,
>
> On Mon, Jul 20, 2026 at 2:30 PM Pauli Virtanen <pav@iki.fi> wrote:
> >
> > iso_sock_disconn() aims to disconnect the hcon by dropping it, which
> > triggers iso_conn_del() once the HCI operation completes, requiring
> > valid hcon->iso_data to do socket cleanup. iso_sock_disconn() sets
> > conn->hcon = NULL to avoid a second drop, but also preventing clearing
> > hcon->iso_data on socket release. Closing the socket before
> > iso_conn_del() runs then results to UAF.
> >
> > Fix by using a separate flag to track the hcon drop status, instead of
> > clearing conn->hcon.
> >
> > Log: (BlueZ iso-tester ISO Connect Close - Success)
> > BUG: KASAN: slab-use-after-free in iso_conn_hold_unless_zero
> > ...
> > iso_conn_hold_unless_zero (net/bluetooth/iso.c:138)
> > iso_conn_del (net/bluetooth/iso.c:270)
> > hci_conn_failed (net/bluetooth/hci_conn.c:1408)
> > hci_abort_conn_sync (net/bluetooth/hci_sync.c:5817)
> >
> > Allocated by task 34:
> > iso_conn_add (net/bluetooth/iso.c:216)
> > iso_connect_cis (net/bluetooth/iso.c:507)
> > iso_sock_connect (net/bluetooth/iso.c:1211)
> > __sys_connect (net/socket.c:2148)
> >
> > Freed by task 34:
> > iso_chan_del (net/bluetooth/iso.c:248)
> > iso_sock_close (net/bluetooth/iso.c:885)
> > iso_sock_release (net/bluetooth/iso.c:2022)
> > sock_close (net/socket.c:722)
> >
> > Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync")
> > Signed-off-by: Pauli Virtanen <pav@iki.fi>
> > ---
> > net/bluetooth/iso.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
> > index 2e95a153912c..6abc2b1f59bc 100644
> > --- a/net/bluetooth/iso.c
> > +++ b/net/bluetooth/iso.c
> > @@ -30,6 +30,7 @@ struct iso_conn {
> > /* @lock: spinlock protecting changes to iso_conn fields */
> > spinlock_t lock;
> > struct sock *sk;
> > + bool hcon_dropped;
>
> It might be safer to add a flag or something so we can perform atomic
> operations to check if dropping is necessary.
It is serialized by iso_conn::lock + kref, so AFAICS it is safe. I can
change it to test_and_set_bit() regardless if still preferable.
The lock is not taken in iso_conn_free() --- at that point nobody is
holding a reference so there should be no concurrent modification, so
AFAIK it is taken care of by the refcount memory ordering (see comment
in include/linux/refcount.h), otherwise conn->hcon etc would also be
wrong.
The
comment https://sashiko.dev/#/patchset/4d96c545ad1a2fed02440a3478905853286aa0c7.1784571683.git.pav%40iki.fi
on Sashiko seems to miss that iso_connect_cfm / iso_disconn_cfm ->
iso_conn_del() are called before hci_conn is deleted, and should make
sure there's no dangling reference to the hci_conn. It would be same as
for remote disconnect. Maybe the prompts it uses in
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/bluetooth.md
could be improved vs hci_conn and socket life cycles.
> > struct delayed_work timeout_work;
> >
> > @@ -107,7 +108,8 @@ static void iso_conn_free(struct kref *ref)
> >
> > if (conn->hcon) {
> > conn->hcon->iso_data = NULL;
> > - hci_conn_drop(conn->hcon);
> > + if (!conn->hcon_dropped)
> > + hci_conn_drop(conn->hcon);
> > }
> >
> > /* Ensure no more work items will run since hci_conn has been dropped */
> > @@ -306,6 +308,7 @@ static int __iso_chan_add(struct iso_conn *conn, struct sock *sk,
> >
> > iso_pi(sk)->conn = conn;
> > conn->sk = sk;
> > + conn->hcon_dropped = false;
> >
> > if (parent)
> > bt_accept_enqueue(parent, sk, true);
> > @@ -836,8 +839,10 @@ static void iso_sock_disconn(struct sock *sk)
> >
> > sk->sk_state = BT_DISCONN;
> > iso_conn_lock(iso_pi(sk)->conn);
> > - hci_conn_drop(iso_pi(sk)->conn->hcon);
> > - iso_pi(sk)->conn->hcon = NULL;
> > + if (!iso_pi(sk)->conn->hcon_dropped) {
> > + iso_pi(sk)->conn->hcon_dropped = true;
> > + hci_conn_drop(iso_pi(sk)->conn->hcon);
> > + }
> > iso_conn_unlock(iso_pi(sk)->conn);
> > }
> >
> > --
> > 2.55.0
> >
>
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: Luiz Augusto von Dentz @ 2026-07-20 20:14 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth, marcel, iulia.tanasescu, linux-kernel
In-Reply-To: <bdf9806d5f2de01e355f0e835201df692f0b2744.camel@iki.fi>
Hi Pauli,
On Mon, Jul 20, 2026 at 4:08 PM Pauli Virtanen <pauli.virtanen@iki.fi> wrote:
>
> Hi Luiz,
>
> ma, 2026-07-20 kello 15:37 -0400, Luiz Augusto von Dentz kirjoitti:
> > Hi Pauli,
> >
> > On Mon, Jul 20, 2026 at 2:30 PM Pauli Virtanen <pav@iki.fi> wrote:
> > >
> > > iso_sock_disconn() aims to disconnect the hcon by dropping it, which
> > > triggers iso_conn_del() once the HCI operation completes, requiring
> > > valid hcon->iso_data to do socket cleanup. iso_sock_disconn() sets
> > > conn->hcon = NULL to avoid a second drop, but also preventing clearing
> > > hcon->iso_data on socket release. Closing the socket before
> > > iso_conn_del() runs then results to UAF.
> > >
> > > Fix by using a separate flag to track the hcon drop status, instead of
> > > clearing conn->hcon.
> > >
> > > Log: (BlueZ iso-tester ISO Connect Close - Success)
> > > BUG: KASAN: slab-use-after-free in iso_conn_hold_unless_zero
> > > ...
> > > iso_conn_hold_unless_zero (net/bluetooth/iso.c:138)
> > > iso_conn_del (net/bluetooth/iso.c:270)
> > > hci_conn_failed (net/bluetooth/hci_conn.c:1408)
> > > hci_abort_conn_sync (net/bluetooth/hci_sync.c:5817)
> > >
> > > Allocated by task 34:
> > > iso_conn_add (net/bluetooth/iso.c:216)
> > > iso_connect_cis (net/bluetooth/iso.c:507)
> > > iso_sock_connect (net/bluetooth/iso.c:1211)
> > > __sys_connect (net/socket.c:2148)
> > >
> > > Freed by task 34:
> > > iso_chan_del (net/bluetooth/iso.c:248)
> > > iso_sock_close (net/bluetooth/iso.c:885)
> > > iso_sock_release (net/bluetooth/iso.c:2022)
> > > sock_close (net/socket.c:722)
> > >
> > > Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync")
> > > Signed-off-by: Pauli Virtanen <pav@iki.fi>
> > > ---
> > > net/bluetooth/iso.c | 11 ++++++++---
> > > 1 file changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
> > > index 2e95a153912c..6abc2b1f59bc 100644
> > > --- a/net/bluetooth/iso.c
> > > +++ b/net/bluetooth/iso.c
> > > @@ -30,6 +30,7 @@ struct iso_conn {
> > > /* @lock: spinlock protecting changes to iso_conn fields */
> > > spinlock_t lock;
> > > struct sock *sk;
> > > + bool hcon_dropped;
> >
> > It might be safer to add a flag or something so we can perform atomic
> > operations to check if dropping is necessary.
>
> It is serialized by iso_conn::lock + kref, so AFAICS it is safe. I can
> change it to test_and_set_bit() regardless if still preferable.
I'm afraid in today's world that is sort of required; otherwise,
someone using an AI model might miss the serialization and send
patches to 'fix' it anyway, just creating more work for us to review.
> The lock is not taken in iso_conn_free() --- at that point nobody is
> holding a reference so there should be no concurrent modification, so
> AFAIK it is taken care of by the refcount memory ordering (see comment
> in include/linux/refcount.h), otherwise conn->hcon etc would also be
> wrong.
>
> The
> comment https://sashiko.dev/#/patchset/4d96c545ad1a2fed02440a3478905853286aa0c7.1784571683.git.pav%40iki.fi
> on Sashiko seems to miss that iso_connect_cfm / iso_disconn_cfm ->
> iso_conn_del() are called before hci_conn is deleted, and should make
> sure there's no dangling reference to the hci_conn. It would be same as
> for remote disconnect. Maybe the prompts it uses in
> https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/bluetooth.md
> could be improved vs hci_conn and socket life cycles.
>
> > > struct delayed_work timeout_work;
> > >
> > > @@ -107,7 +108,8 @@ static void iso_conn_free(struct kref *ref)
> > >
> > > if (conn->hcon) {
> > > conn->hcon->iso_data = NULL;
> > > - hci_conn_drop(conn->hcon);
> > > + if (!conn->hcon_dropped)
> > > + hci_conn_drop(conn->hcon);
> > > }
> > >
> > > /* Ensure no more work items will run since hci_conn has been dropped */
> > > @@ -306,6 +308,7 @@ static int __iso_chan_add(struct iso_conn *conn, struct sock *sk,
> > >
> > > iso_pi(sk)->conn = conn;
> > > conn->sk = sk;
> > > + conn->hcon_dropped = false;
> > >
> > > if (parent)
> > > bt_accept_enqueue(parent, sk, true);
> > > @@ -836,8 +839,10 @@ static void iso_sock_disconn(struct sock *sk)
> > >
> > > sk->sk_state = BT_DISCONN;
> > > iso_conn_lock(iso_pi(sk)->conn);
> > > - hci_conn_drop(iso_pi(sk)->conn->hcon);
> > > - iso_pi(sk)->conn->hcon = NULL;
> > > + if (!iso_pi(sk)->conn->hcon_dropped) {
> > > + iso_pi(sk)->conn->hcon_dropped = true;
> > > + hci_conn_drop(iso_pi(sk)->conn->hcon);
> > > + }
> > > iso_conn_unlock(iso_pi(sk)->conn);
> > > }
> > >
> > > --
> > > 2.55.0
> > >
> >
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 0/5] Bluetooth: harden packet and transport parsing
From: patchwork-bot+bluetooth @ 2026-07-20 20:20 UTC (permalink / raw)
To: Li Qiang; +Cc: linux-bluetooth, marcel, luiz.dentz, linux-kernel
In-Reply-To: <cover.1784191283.git.liqiang01@kylinos.cn>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 16 Jul 2026 16:47:27 +0800 you wrote:
> This series hardens Bluetooth packet receive paths and the HCI UART
> transmit path against malformed lengths and invalid callback return
> values.
>
> The affected code accesses protocol fields before confirming that the
> complete headers are present, or trusts a received length while
> appending to an skb. The HCI UART write worker also assumes that a tty
> driver always returns a valid written-byte count. These assumptions can
> lead to out-of-bounds accesses or invalid skb manipulation when data is
> truncated or a lower-level driver reports an invalid result.
>
> [...]
Here is the summary with links:
- [1/5] Bluetooth: bfusb: validate received block boundaries
https://git.kernel.org/bluetooth/bluetooth-next/c/b94bab6f1dd9
- [2/5] Bluetooth: btmrvl: validate event packet lengths
https://git.kernel.org/bluetooth/bluetooth-next/c/75e574f6a212
- [3/5] Bluetooth: hci_bcsp: validate received packet lengths
https://git.kernel.org/bluetooth/bluetooth-next/c/a4c72c8c7cef
- [4/5] Bluetooth: hci_ldisc: reject invalid tty write lengths
https://git.kernel.org/bluetooth/bluetooth-next/c/5afe69c190c4
- [5/5] Bluetooth: hci_qca: validate controller memdump frames
(no matching commit)
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 v2] Bluetooth: btusb: validate Realtek vendor event length
From: patchwork-bot+bluetooth @ 2026-07-20 20:20 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: marcel, luiz.dentz, pmenzel, linux-bluetooth, linux-kernel
In-Reply-To: <20260720114717.60749-1-pengpeng@iscas.ac.cn>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 20 Jul 2026 19:47:17 +0800 you wrote:
> btusb_recv_event_realtek() reads the event code at data[0] and the Realtek
> subevent code at data[2] before deciding whether to consume a vendor event
> as a coredump.
>
> For example, the two-byte event ff 00 contains a complete vendor-event
> header declaring zero parameters. The old classifier still reads a
> nonexistent third byte and can misclassify the event as a coredump if the
> adjacent byte is 0x34.
>
> [...]
Here is the summary with links:
- [v2] Bluetooth: btusb: validate Realtek vendor event length
https://git.kernel.org/bluetooth/bluetooth-next/c/891916abe16f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: RFCOMM: Fix session UAF in set_termios
From: patchwork-bot+bluetooth @ 2026-07-20 20:20 UTC (permalink / raw)
To: Chengfeng Ye
Cc: marcel, luiz.dentz, kees, kuba, suunj1331, dg573847474, tim.bird,
pengpeng, johan, hadess, jsuter, davem, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <20260719160311.2898053-1-nicoyip.dev@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 20 Jul 2026 00:03:11 +0800 you wrote:
> rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and
> later passes the pointer to rfcomm_send_rpn(). The latter dereferences
> both session->initiator and session->sock. Meanwhile, krfcommd can
> unlink the DLC and free the session while holding rfcomm_mutex.
>
> The race can proceed as follows:
>
> [...]
Here is the summary with links:
- Bluetooth: RFCOMM: Fix session UAF in set_termios
https://git.kernel.org/bluetooth/bluetooth-next/c/2ac5f666025e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_sync: Protect UUID list traversal
From: patchwork-bot+bluetooth @ 2026-07-20 20:20 UTC (permalink / raw)
To: Chengfeng Ye; +Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, stable
In-Reply-To: <20260719162427.2902105-1-nicoyip.dev@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 20 Jul 2026 00:24:27 +0800 you wrote:
> The hci_sync conversion moved class-of-device and EIR generation from an
> HCI request built under hdev->lock to asynchronous command sync work.
> The worker holds hdev->req_lock, but that lock does not serialize access
> to hdev->uuids against add_uuid() and remove_uuid(), which update the
> list under hdev->lock.
>
> The following interleaving can therefore occur:
>
> [...]
Here is the summary with links:
- Bluetooth: hci_sync: Protect UUID list traversal
https://git.kernel.org/bluetooth/bluetooth-next/c/9348bd469f56
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [v2] Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v1()
From: bluez.test.bot @ 2026-07-20 20:27 UTC (permalink / raw)
To: linux-bluetooth, doruk
In-Reply-To: <20260720191322.14432-1-doruk@0sec.ai>
[-- Attachment #1: Type: text/plain, Size: 1468 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=1131114
---Test result---
Test Summary:
CheckPatch PASS 0.65 seconds
VerifyFixes PASS 0.10 seconds
VerifySignedoff PASS 0.14 seconds
GitLint FAIL 0.26 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 24.54 seconds
CheckAllWarning PASS 27.46 seconds
CheckSparse PASS 26.13 seconds
BuildKernel32 PASS 24.39 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 451.97 seconds
IncrementalBuild PASS 24.16 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v1()
1: T1 Title exceeds max length (82>80): "[v2] Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v1()"
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/466
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v2] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: bluez.test.bot @ 2026-07-20 20:30 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <4d96c545ad1a2fed02440a3478905853286aa0c7.1784571683.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1131089
---Test result---
Test Summary:
CheckPatch PASS 0.58 seconds
VerifyFixes PASS 0.08 seconds
VerifySignedoff PASS 0.09 seconds
GitLint PASS 0.21 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 27.98 seconds
CheckAllWarning PASS 30.13 seconds
CheckSparse PASS 29.14 seconds
BuildKernel32 PASS 27.30 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 518.84 seconds
TestRunner_iso-tester PASS 84.67 seconds
IncrementalBuild PASS 26.36 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/465
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] tools/iso-tester: fix GIOChannel refcounting
From: bluez.test.bot @ 2026-07-20 20:35 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <77c23b3b0b0b0be0ce52e5718f88f8723dabf7ee.1784571951.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1131086
---Test result---
Test Summary:
CheckPatch PASS 1.43 seconds
GitLint PASS 0.32 seconds
BuildEll PASS 20.37 seconds
BluezMake PASS 498.03 seconds
CheckSmatch PASS 296.18 seconds
bluezmakeextell PASS 95.09 seconds
IncrementalBuild PASS 496.49 seconds
ScanBuild PASS 882.20 seconds
https://github.com/bluez/bluez/pull/2334
---
Regards,
Linux Bluetooth
^ permalink raw reply
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