* RE: arm64: dts: monaco-arduino-monza: Add support for LGA WiFi/BT module
From: bluez.test.bot @ 2026-07-20 9:51 UTC (permalink / raw)
To: linux-bluetooth, loic.poulain
In-Reply-To: <20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: drivers/power/sequencing/core.c:991
error: drivers/power/sequencing/core.c: patch does not apply
error: patch failed: include/linux/pwrseq/consumer.h:25
error: include/linux/pwrseq/consumer.h: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v2] Bluetooth: btusb: validate Realtek vendor event length
From: Pengpeng Hou @ 2026-07-20 11:47 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Paul Menzel, linux-bluetooth, linux-kernel, Pengpeng Hou
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.
Require the HCI event header and first parameter to be present before
inspecting the Realtek subevent code. Short events continue through the
normal HCI receive path, which owns their protocol validation.
Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1: https://lore.kernel.org/all/20260706091618.77442-1-pengpeng@iscas.ac.cn/
- clarify both fixed-offset reads and add a concrete short event
- add the requested Fixes tag
- rebase onto v7.2-rc4
drivers/bluetooth/btusb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 08c0a99a62c5..8f7ed469cac6 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2782,7 +2782,9 @@ static int btusb_setup_realtek(struct hci_dev *hdev)
static int btusb_recv_event_realtek(struct hci_dev *hdev, struct sk_buff *skb)
{
- if (skb->data[0] == HCI_VENDOR_PKT && skb->data[2] == RTK_SUB_EVENT_CODE_COREDUMP) {
+ if (skb->len >= HCI_EVENT_HDR_SIZE + 1 &&
+ skb->data[0] == HCI_VENDOR_PKT &&
+ skb->data[2] == RTK_SUB_EVENT_CODE_COREDUMP) {
struct rtk_dev_coredump_hdr hdr = {
.code = RTK_DEVCOREDUMP_CODE_MEMDUMP,
};
^ permalink raw reply related
* RE: [v2] Bluetooth: btusb: validate Realtek vendor event length
From: bluez.test.bot @ 2026-07-20 12:33 UTC (permalink / raw)
To: linux-bluetooth, pengpeng
In-Reply-To: <20260720114717.60749-1-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1130844
---Test result---
Test Summary:
CheckPatch PASS 0.71 seconds
VerifyFixes PASS 0.12 seconds
VerifySignedoff PASS 0.12 seconds
GitLint PASS 0.31 seconds
SubjectPrefix PASS 0.11 seconds
BuildKernel PASS 26.03 seconds
CheckAllWarning PASS 29.79 seconds
CheckSparse PASS 27.74 seconds
BuildKernel32 PASS 24.87 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 469.33 seconds
IncrementalBuild PASS 29.93 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/461
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH BlueZ v4 2/2] profiles: Register RAS UUID reactively instead of probing
From: Naga Bhavani Akella @ 2026-07-20 12:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, quic_mohamull, quic_hbandi, quic_anubhavg
In-Reply-To: <CABBYNZLpp-hMUrevPX=_qD5F6Jh2yH+mLJD03A+PSQsBErxAUA@mail.gmail.com>
Hi Luiz,
On 7/17/2026 7:36 PM, Luiz Augusto von Dentz wrote:
> Hi Naga,
>
> On Fri, Jul 17, 2026 at 10:02 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>>
>> Hi Naga,
>>
>> On Fri, Jul 17, 2026 at 8:41 AM Naga Bhavani Akella
>> <naga.akella@oss.qualcomm.com> wrote:
>>>
>>> Replace the unconditional reflector-role GATT_UUID probe in
>>> gatt_client_init() with a reactive registration driven by actual
>>> remote RAS access, using the notification API added in shared/rap.
>>
>> It seems you already have something like that in bt_rap_register
>> attached callback, it is just never used, which explains why
>> rap_attached is never called and you need the likes of probe in order
>> to create rap_data_new.
>
> In case I wasn't clear, I meant shared/bap.c needs to call
> rap->attached callback whenever a session is connected, just follow
> what was done in the likes of shared/bap.c which does bt_bap_attach ->
> bap->attached, so bt_rap_attach shall probably call rap->attached.
>
Understood. I will include the requested changes in the next revision.>>
>>> ---
>>> profiles/ranging/rap.c | 25 +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
>>> index 3ffc0da76..4f6d7f2db 100644
>>> --- a/profiles/ranging/rap.c
>>> +++ b/profiles/ranging/rap.c
>>> @@ -308,6 +308,27 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
>>> rap_data_add(data);
>>> }
>>>
>>> +static void rap_ras_accessed(struct bt_att *att, void *user_data)
>>> +{
>>> + struct btd_device *device;
>>> + struct btd_service *service;
>>> +
>>> + device = btd_adapter_find_device_by_fd(bt_att_get_fd(att));
>>> + if (!device) {
>>> + error("unable to find device for RAS access");
>>> + return;
>>> + }
>>> +
>>> + service = btd_device_get_service(device, GATT_UUID);
>>> + if (!service) {
>>> + btd_device_add_uuid(device, GATT_UUID);
>>> + service = btd_device_get_service(device, GATT_UUID);
>>> + }
>>> +
>>> + if (service)
>>> + service_accept(service, btd_device_is_initiator(device));
>>> +}
>>> +
>>> enum cs_dict_target {
>>> CS_TARGET_SETTINGS,
>>> CS_TARGET_CFG,
>>> @@ -830,6 +851,7 @@ static struct btd_profile rap_profile = {
>>> };
>>>
>>> static unsigned int rap_id;
>>> +static unsigned int rap_ras_accessed_id;
>>>
>>> static int rap_init(void)
>>> {
>>> @@ -840,6 +862,8 @@ static int rap_init(void)
>>> return err;
>>>
>>> rap_id = bt_rap_register(rap_attached, rap_detached, NULL);
>>> + rap_ras_accessed_id = bt_rap_ras_accessed_register(rap_ras_accessed,
>>> + NULL);
>>>
>>> return 0;
>>> }
>>> @@ -848,6 +872,7 @@ static void rap_exit(void)
>>> {
>>> btd_profile_unregister(&rap_profile);
>>> bt_rap_unregister(rap_id);
>>> + bt_rap_ras_accessed_unregister(rap_ras_accessed_id);
>>> }
>>>
>>> BLUETOOTH_PLUGIN_DEFINE(rap, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
>>> --
>>>
>>
>>
>> --
>> Luiz Augusto von Dentz
>
>
>
Thanks,
Bhavani
^ permalink raw reply
* Re: [PATCH] Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev
From: Bartosz Golaszewski @ 2026-07-20 13:48 UTC (permalink / raw)
To: raoxu
Cc: marcel, luiz.dentz, linux-arm-msm, linux-bluetooth, linux-kernel,
stable, brgl
In-Reply-To: <0CB2D8D715AB9933+20260713072543.3348755-1-raoxu@uniontech.com>
On Mon, 13 Jul 2026 09:25:43 +0200, raoxu <raoxu@uniontech.com> said:
> From: Xu Rao <raoxu@uniontech.com>
>
> The command and ACL RPMsg endpoints store struct btqcomsmd as their
> callback private data. The receive callbacks dereference btq->hdev
> without taking an hci_dev reference.
>
> The current teardown order frees the hci_dev before destroying the RPMsg
> endpoints in both the hci_register_dev() error path and the driver remove
> path. If WCNSS delivers data in that window, the endpoint callback can
> run with an already freed hci_dev and pass it to the Bluetooth core.
>
> For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears
> the callback under the channel recv_lock. The receive path holds the same
> lock while invoking the callback, so destroying the endpoints first both
> prevents new callbacks and serializes with any callback already running.
>
> Destroy the command and ACL endpoints before hci_free_dev(). Keep
> hci_unregister_dev() first during remove so the HCI core stops issuing
> operations before the transport endpoints are shut down. In the full
> registration-error cleanup path, return directly after freeing the hci_dev
> to avoid falling through to the partial-construction labels and destroying
> the endpoints twice.
>
> Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg")
> Fixes: 9a39a927be01 ("Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> ---
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH BlueZ] test-runner: use virtio for the default kernel console
From: Pauli Virtanen @ 2026-07-20 14:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pauli Virtanen
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
---
tools/test-runner.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/tools/test-runner.c b/tools/test-runner.c
index 0e3bfb8b7..4617afc63 100644
--- a/tools/test-runner.c
+++ b/tools/test-runner.c
@@ -238,6 +238,8 @@ static char *const qemu_argv[] = {
"-device", "virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root",
"-chardev", "stdio,id=con,mux=on",
"-serial", "chardev:con",
+ "-device", "virtio-serial",
+ "-device", "virtconsole,chardev=con,name=console.0",
NULL
};
@@ -291,7 +293,7 @@ static void start_qemu(void)
}
snprintf(cmdline, sizeof(cmdline),
- "console=ttyS0,115200n8 earlyprintk=serial "
+ "console=hvc0 earlyprintk=serial "
"no_hash_pointers=1 rootfstype=9p "
"rootflags=trans=virtio,version=9p2000.u "
"acpi=off pci=noacpi noapic quiet ro init=%s "
@@ -330,11 +332,6 @@ static void start_qemu(void)
argv[pos++] = "-append";
argv[pos++] = (char *) cmdline;
- if (num_devs) {
- argv[pos++] = "-device";
- argv[pos++] = "virtio-serial";
- }
-
for (i = 0; i < num_devs; i++) {
char *chrdev, *serdev;
@@ -915,7 +912,7 @@ static void run_command(char *cmdname, char *home)
}
if (num_devs) {
- const char *node = "/dev/hvc0";
+ const char *node = "/dev/hvc1";
unsigned int basic_flags, extra_flags;
printf("Attaching BR/EDR controller to %s\n", node);
--
2.55.0
^ permalink raw reply related
* Re: [PATCH bluez RFC 2/3] doc: hci-protocol: Add sock option BT_RCV_VENDOR_PKT for HCI_CHANNEL_USER
From: Luiz Augusto von Dentz @ 2026-07-20 14:10 UTC (permalink / raw)
To: Zijun Hu; +Cc: Marcel Holtmann, Zijun Hu, linux-bluetooth, linux-kernel
In-Reply-To: <20260719-vendor_hci-v1-2-df2ac5a50117@oss.qualcomm.com>
Hi,
On Mon, Jul 20, 2026 at 1:41 AM Zijun Hu <zijun.hu@oss.qualcomm.com> wrote:
>
> BT_RCV_VENDOR_PKT was introduced to support vendor HCI frame.
> ---
> doc/hci-protocol.rst | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/doc/hci-protocol.rst b/doc/hci-protocol.rst
> index db10b35df736..91cbc5b65a78 100644
> --- a/doc/hci-protocol.rst
> +++ b/doc/hci-protocol.rst
> @@ -136,6 +136,24 @@ Example:
> len = sizeof(mtu);
> err = getsockopt(sock, SOL_BLUETOOTH, BT_RCVMTU, &mtu, &len);
>
> +BT_RCV_VENDOR_PKT (since Linux 7.3)
> +-----------------------------------
> +
> +Enable receiving vendor HCI frames, requires hci_channel to be set to
> +HCI_CHANNEL_USER.
> +
> +Default is disabled.
> +
> +Example:
> +
> +.. code-block::
> +
> + int enable = 1;
> + int err;
> +
> + err = setsockopt(fd, SOL_BLUETOOTH, BT_RCV_VENDOR_PKT, &enable,
> + sizeof(enable));
> +
I don't think we have any socket option with this name, besides this
should really go as an HCI packet with an H4 header set accordingly.
> RESOURCES
> =========
>
>
> --
> 2.34.1
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH RFC] Bluetooth: Add generic support for vendor HCI frames
From: Luiz Augusto von Dentz @ 2026-07-20 14:30 UTC (permalink / raw)
To: Zijun Hu; +Cc: Marcel Holtmann, Zijun Hu, linux-bluetooth, linux-kernel
In-Reply-To: <20260719-support_vendor_hci-v1-1-764523a4ca3d@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 15937 bytes --]
Hi Zijun,
On Mon, Jul 20, 2026 at 1:14 AM Zijun Hu <zijun.hu@oss.qualcomm.com> wrote:
>
> For Qualcomm multi-subsystem BT chips, the transport wire carries both
> BT-HCI and PERI-HCI frames. PERI is a subsystem on the chip. Take the
> upcoming QCC2072 support as an example:
>
> Packet type BT-HCI indicator PERI-HCI indicator
> --------------------------------------------------------------
> CMD (Host -> Controller) 0x01 0x31
> ACL Data (bidirectional) 0x02 0x32
> EVENT (Controller -> Host) 0x04 0x34
I would say this was fine, but you actuall need to reclassify these to
0xff and then use an extra byte for the vendor opcode. Btw, you said
you could define H4 headers like this? The spec defines either:
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core_v6.3/out/en/host-controller-interface/three-wire-uart-transport-layer.html#UUID-1cf959bb-57a0-e782-4324-a9bc4ee3f134_table-idm13359018144714
Or
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core_v6.3/out/en/host-controller-interface/uart-transport-layer.html#UUID-83881875-5fbb-c366-400f-055ba726f70e_table-idm13359015052542
We end up defining vendor 0xff because it is at the end of the range
which is probably safer.
> To generically support vendor HCI frames:
>
> - Show them in btmon logs as they appear on the wire.
> - Allow userspace to send/receive them via HCI_CHANNEL_USER, with a
> socket option to control RX, defaulting off to eliminate regression
> risk for existing applications.
We shouldn't need to do this, we should just accept 0xff as the vendor
packet type and then use the following byte as the real opcode (0x31,
0x32, 0x34). Otherwise, if we start accepting vendor packet types
outside 0xff this will get crowded quickly and could potentially clash
with future specs.
> - Add hdev->recv_vendor() to handle vendor frames in hci_rx_work() like
> BT frame handlers.
> - Add hci_send_vendor_frame() API similar to existing __hci_cmd_send().
Encoding/decoding of the frames should be transparent. I'm fine adding
code to the likes of btmon to decode vendor packets, we already have
something similar for Intel although that uses a vendor event not a
vendor packet (both use 0xff, causing the confusion). The user of the
user channel shall be able to read/write starting with 0xff then
decode/encode the next byte as the actual vendor opcode.
> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
> ---
> Hi Luiz
> To address the below concerns you raised on previous
> discussion, and inspired from your suggestion to add hdev callback:
>
> - Not use safer skb helper like skb_pull_data()
> - It will skip sending to the monitor, making debugging much harder
>
> Looking forward to your further comments.
>
> Why hdev->is_vendor() instead of multiplexing vendor frames under a
> virtual HCI_VENDOR_PKT + vendor indicator byte ?
>
> 1) The virtual HCI_VENDOR_PKT isn't used by the core itself
> currently, and may be removed later.
> 2) It makes full use of the indicator (hci_skb_pkt_type(skb)) space,
> which is large enough to accommodate vendor frames without an
> extra layer of nesting inside HCI_VENDOR_PKT.
> 3) It lets userspace and btmon logs see the exact same frame as it
> appears on the wire.
>
> Previous discussion link:
> https://lore.kernel.org/all/CABBYNZJpdeoZ16bObLRPhng2dfyNeK9ix9_-z_hMZhJ0QxTxGg@mail.gmail.com
> https://lore.kernel.org/all/CABBYNZJ0zoVVVxuM48L=Km==gnrQuskrbjB6q_aNV0KEEY3+5w@mail.gmail.com
> ---
> include/net/bluetooth/bluetooth.h | 2 +
> include/net/bluetooth/hci.h | 1 +
> include/net/bluetooth/hci_core.h | 13 +++++++
> include/net/bluetooth/hci_mon.h | 2 +
> net/bluetooth/hci_core.c | 22 +++++++++++
> net/bluetooth/hci_sock.c | 78 ++++++++++++++++++++++++++++++++++-----
> 6 files changed, 108 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index b624da5026f5..d9870a43a2c4 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -256,6 +256,8 @@ struct bt_codecs {
>
> #define BT_SCM_PKT_SEQNUM 0x05
>
> +#define BT_RCV_VENDOR_PKT 23
> +
> __printf(1, 2)
> void bt_info(const char *fmt, ...);
> __printf(1, 2)
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 50f0eef71fb1..ac97550cbdba 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -398,6 +398,7 @@ enum {
> /* HCI socket flags */
> enum {
> HCI_SOCK_TRUSTED,
> + HCI_SOCK_RCV_VENDOR_PKT,
> HCI_MGMT_INDEX_EVENTS,
> HCI_MGMT_UNCONF_INDEX_EVENTS,
> HCI_MGMT_EXT_INDEX_EVENTS,
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index e7133ff87fbf..20a455d90ef3 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -645,6 +645,8 @@ struct hci_dev {
> int (*setup)(struct hci_dev *hdev);
> int (*shutdown)(struct hci_dev *hdev);
> int (*send)(struct hci_dev *hdev, struct sk_buff *skb);
> + bool (*is_vendor)(struct hci_dev *hdev, const struct sk_buff *skb);
> + void (*recv_vendor)(struct hci_dev *hdev, struct sk_buff *skb);
> void (*notify)(struct hci_dev *hdev, unsigned int evt);
> void (*hw_error)(struct hci_dev *hdev, u8 code);
> int (*post_init)(struct hci_dev *hdev);
> @@ -660,6 +662,15 @@ struct hci_dev {
> u8 (*classify_pkt_type)(struct hci_dev *hdev, struct sk_buff *skb);
> };
>
> +static inline bool hci_is_vendor_frame(struct hci_dev *hdev,
> + const struct sk_buff *skb)
> +{
> + if (!hdev->is_vendor)
> + return false;
> +
> + return hdev->is_vendor(hdev, skb);
> +}
> +
> #define hci_set_quirk(hdev, nr) set_bit((nr), (hdev)->quirk_flags)
> #define hci_clear_quirk(hdev, nr) clear_bit((nr), (hdev)->quirk_flags)
> #define hci_test_quirk(hdev, nr) test_bit((nr), (hdev)->quirk_flags)
> @@ -2327,6 +2338,8 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
> int hci_register_cb(struct hci_cb *hcb);
> int hci_unregister_cb(struct hci_cb *hcb);
>
> +int hci_send_vendor_frame(struct hci_dev *hdev, struct sk_buff *skb);
> +
> int __hci_cmd_send(struct hci_dev *hdev, u16 opcode, u32 plen,
> const void *param);
>
> diff --git a/include/net/bluetooth/hci_mon.h b/include/net/bluetooth/hci_mon.h
> index 4b2a0af4ed58..7710688c0d30 100644
> --- a/include/net/bluetooth/hci_mon.h
> +++ b/include/net/bluetooth/hci_mon.h
> @@ -50,6 +50,8 @@ struct hci_mon_hdr {
> #define HCI_MON_ISO_RX_PKT 19
> #define HCI_MON_DRV_TX_PKT 20
> #define HCI_MON_DRV_RX_PKT 21
> +#define HCI_MON_VENDOR_TX_PKT 22
> +#define HCI_MON_VENDOR_RX_PKT 23
>
> struct hci_mon_new_index {
> __u8 type;
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 1e324c05af24..c12c180e8293 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2920,6 +2920,8 @@ int hci_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
> case HCI_DRV_PKT:
> break;
> default:
> + if (hci_is_vendor_frame(hdev, skb))
> + break;
> kfree_skb(skb);
> return -EINVAL;
> }
> @@ -3053,6 +3055,18 @@ static int hci_send_conn_frame(struct hci_dev *hdev, struct hci_conn *conn,
> return hci_send_frame(hdev, skb);
> }
>
> +int hci_send_vendor_frame(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + if (hci_is_vendor_frame(hdev, skb))
> + return hci_send_frame(hdev, skb);
> +
> + bt_dev_err(hdev, "invalid vendor frame with pkt_type 0x%2.2x",
> + hci_skb_pkt_type(skb));
> + kfree_skb(skb);
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(hci_send_vendor_frame);
> +
> /* Send HCI command */
> int hci_send_cmd(struct hci_dev *hdev, __u16 opcode, __u32 plen,
> const void *param)
> @@ -4066,6 +4080,14 @@ static void hci_rx_work(struct work_struct *work)
> break;
>
> default:
> + if (hci_is_vendor_frame(hdev, skb)) {
> + BT_DBG("%s Vendor packet with type 0x%2.2x",
> + hdev->name, hci_skb_pkt_type(skb));
> + if (hdev->recv_vendor) {
> + hdev->recv_vendor(hdev, skb);
> + break;
> + }
> + }
> kfree_skb(skb);
> break;
> }
> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> index 070ca388f9ac..903498e6db3d 100644
> --- a/net/bluetooth/hci_sock.c
> +++ b/net/bluetooth/hci_sock.c
> @@ -229,12 +229,16 @@ void hci_send_to_sock(struct hci_dev *hdev, struct sk_buff *skb)
> } else if (hci_pi(sk)->channel == HCI_CHANNEL_USER) {
> if (!bt_cb(skb)->incoming)
> continue;
> - if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT &&
> - hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
> - hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
> - hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
> - hci_skb_pkt_type(skb) != HCI_DRV_PKT)
> + if (hci_is_vendor_frame(hdev, skb)) {
> + if (!hci_sock_test_flag(sk, HCI_SOCK_RCV_VENDOR_PKT))
> + continue;
> + } else if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT &&
> + hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
> + hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
> + hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
> + hci_skb_pkt_type(skb) != HCI_DRV_PKT) {
> continue;
> + }
> } else {
> /* Don't send frame to other channel types */
> continue;
> @@ -359,6 +363,7 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
> struct sk_buff *skb_copy = NULL;
> struct hci_mon_hdr *hdr;
> __le16 opcode;
> + bool is_vendor_frame = false;
>
> if (!atomic_read(&monitor_promisc))
> return;
> @@ -400,7 +405,26 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
> opcode = cpu_to_le16(HCI_MON_VENDOR_DIAG);
> break;
> default:
> - return;
> + is_vendor_frame = hci_is_vendor_frame(hdev, skb);
> + if (!is_vendor_frame)
> + return;
> + if (bt_cb(skb)->incoming)
> + opcode = cpu_to_le16(HCI_MON_VENDOR_RX_PKT);
> + else
> + opcode = cpu_to_le16(HCI_MON_VENDOR_TX_PKT);
> + break;
> + }
> +
> + if (is_vendor_frame) {
> + skb_copy = __pskb_copy_fclone(skb, HCI_MON_HDR_SIZE + 1,
> + GFP_ATOMIC, true);
> + if (!skb_copy)
> + return;
> +
> + *(u8 *)skb_push(skb_copy, 1) = hci_skb_pkt_type(skb);
> + hdr = skb_push(skb_copy, HCI_MON_HDR_SIZE);
> + hdr->len = cpu_to_le16(skb->len + 1);
> + goto out_comm;
> }
>
> /* Create a private copy with headroom */
> @@ -408,14 +432,15 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
> if (!skb_copy)
> return;
>
> - hci_sock_copy_creds(skb->sk, skb_copy);
> -
> /* Put header before the data */
> hdr = skb_push(skb_copy, HCI_MON_HDR_SIZE);
> + hdr->len = cpu_to_le16(skb->len);
> +
> +out_comm:
> hdr->opcode = opcode;
> hdr->index = cpu_to_le16(hdev->id);
> - hdr->len = cpu_to_le16(skb->len);
>
> + hci_sock_copy_creds(skb->sk, skb_copy);
> hci_send_to_channel(HCI_CHANNEL_MONITOR, skb_copy,
> HCI_SOCK_TRUSTED, NULL);
> kfree_skb(skb_copy);
> @@ -1868,7 +1893,8 @@ static int hci_sock_sendmsg(struct socket *sock, struct msghdr *msg,
> hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
> hci_skb_pkt_type(skb) != HCI_SCODATA_PKT &&
> hci_skb_pkt_type(skb) != HCI_ISODATA_PKT &&
> - hci_skb_pkt_type(skb) != HCI_DRV_PKT) {
> + hci_skb_pkt_type(skb) != HCI_DRV_PKT &&
> + !hci_is_vendor_frame(hdev, skb)) {
> err = -EINVAL;
> goto drop;
> }
> @@ -2017,6 +2043,7 @@ static int hci_sock_setsockopt(struct socket *sock, int level, int optname,
> {
> struct sock *sk = sock->sk;
> int err = 0;
> + int opt_int;
> u16 opt;
>
> BT_DBG("sk %p, opt %d", sk, optname);
> @@ -2050,6 +2077,23 @@ static int hci_sock_setsockopt(struct socket *sock, int level, int optname,
> hci_pi(sk)->mtu = opt;
> break;
>
> + case BT_RCV_VENDOR_PKT:
> + if (hci_pi(sk)->channel != HCI_CHANNEL_USER) {
> + err = -ENOPROTOOPT;
> + break;
> + }
> +
> + err = copy_safe_from_sockptr(&opt_int, sizeof(opt_int),
> + optval, optlen);
> + if (err)
> + break;
> +
> + if (opt_int)
> + hci_sock_set_flag(sk, HCI_SOCK_RCV_VENDOR_PKT);
> + else
> + hci_sock_clear_flag(sk, HCI_SOCK_RCV_VENDOR_PKT);
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
> @@ -2132,6 +2176,7 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname,
> {
> struct sock *sk = sock->sk;
> int err = 0;
> + int opt_int;
> u16 mtu;
>
> BT_DBG("sk %p, opt %d", sk, optname);
> @@ -2153,6 +2198,19 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname,
> err = -EFAULT;
> break;
>
> + case BT_RCV_VENDOR_PKT:
> + if (hci_pi(sk)->channel != HCI_CHANNEL_USER) {
> + err = -ENOPROTOOPT;
> + break;
> + }
> +
> + opt_int = hci_sock_test_flag(sk, HCI_SOCK_RCV_VENDOR_PKT) ?
> + 1 : 0;
> + if (copy_to_iter(&opt_int, sizeof(opt_int),
> + &sopt->iter_out) != sizeof(opt_int))
> + err = -EFAULT;
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
>
> ---
> base-commit: 7f02cdbb4cf17df8aa1977eea0cf490c472a706d
> change-id: 20260719-support_vendor_hci-1fbb4449ab8e
>
> Best regards,
> --
> Zijun Hu <zijun.hu@oss.qualcomm.com>
>
--
Luiz Augusto von Dentz
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 47751 bytes --]
^ permalink raw reply
* [bluez/bluez] 294a72: test-runner: use virtio for the default kernel con...
From: Pauli Virtanen @ 2026-07-20 14:39 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1130938
Home: https://github.com/bluez/bluez
Commit: 294a7255707265bba4a97b5ea93c55cf793db826
https://github.com/bluez/bluez/commit/294a7255707265bba4a97b5ea93c55cf793db826
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
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH] Bluetooth: ISO: clear iso_data always when detaching conn from hcon
From: Pauli Virtanen @ 2026-07-20 14:53 UTC (permalink / raw)
To: linux-bluetooth
Cc: Pauli Virtanen, marcel, luiz.dentz, iulia.tanasescu, linux-kernel
When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is
necessary, otherwise later iso_conn_free() will UAF.
Fix clearing of iso_data in iso_sock_disconn()
Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on
iso_sock_release() followed by hci_abort_conn_sync().
Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
---
Notes:
The locking around iso_data and conn->hcon access looks wrong here,
there's very likely concurrency bugs with UAF here. These should be
fixed in separate series.
net/bluetooth/iso.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index 2e95a153912c..babba61eb335 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -837,6 +837,7 @@ 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->iso_data = NULL;
iso_pi(sk)->conn->hcon = NULL;
iso_conn_unlock(iso_pi(sk)->conn);
}
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev
From: Dmitry Baryshkov @ 2026-07-20 14:53 UTC (permalink / raw)
To: raoxu
Cc: brgl, marcel, luiz.dentz, linux-arm-msm, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <0CB2D8D715AB9933+20260713072543.3348755-1-raoxu@uniontech.com>
On Mon, Jul 13, 2026 at 03:25:43PM +0800, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> The command and ACL RPMsg endpoints store struct btqcomsmd as their
> callback private data. The receive callbacks dereference btq->hdev
> without taking an hci_dev reference.
>
> The current teardown order frees the hci_dev before destroying the RPMsg
> endpoints in both the hci_register_dev() error path and the driver remove
> path. If WCNSS delivers data in that window, the endpoint callback can
> run with an already freed hci_dev and pass it to the Bluetooth core.
>
> For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears
> the callback under the channel recv_lock. The receive path holds the same
> lock while invoking the callback, so destroying the endpoints first both
> prevents new callbacks and serializes with any callback already running.
>
> Destroy the command and ACL endpoints before hci_free_dev(). Keep
> hci_unregister_dev() first during remove so the HCI core stops issuing
> operations before the transport endpoints are shut down. In the full
> registration-error cleanup path, return directly after freeing the hci_dev
> to avoid falling through to the partial-construction labels and destroying
> the endpoints twice.
>
> Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg")
> Fixes: 9a39a927be01 ("Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> ---
> drivers/bluetooth/btqcomsmd.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [BlueZ] test-runner: use virtio for the default kernel console
From: bluez.test.bot @ 2026-07-20 15:11 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <e71384747c71a2fa0db585acdb727f324161d1b8.1784554811.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=1130938
---Test result---
Test Summary:
CheckPatch PASS 0.33 seconds
GitLint PASS 0.24 seconds
BuildEll PASS 16.62 seconds
BluezMake PASS 475.48 seconds
CheckSmatch PASS 232.13 seconds
bluezmakeextell PASS 73.76 seconds
IncrementalBuild PASS 398.22 seconds
ScanBuild PASS 691.41 seconds
https://github.com/bluez/bluez/pull/2333
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: fix BT dependency for submodules
From: Iva Kasprzaková @ 2026-07-20 15:09 UTC (permalink / raw)
To: marcel, luiz.dentz, linux-bluetooth
Cc: xrabek1, xkasprz, Iva Kasprzaková
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
^ permalink raw reply related
* Re: [PATCH] Bluetooth: ISO: clear iso_data always when detaching conn from hcon
From: Pauli Virtanen @ 2026-07-20 15:47 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.dentz, iulia.tanasescu, linux-kernel
In-Reply-To: <f3d8d52dcb2a5464393623a56369ea244c144460.1784559155.git.pav@iki.fi>
Hi,
ma, 2026-07-20 kello 17:53 +0300, Pauli Virtanen kirjoitti:
> When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is
> necessary, otherwise later iso_conn_free() will UAF.
>
> Fix clearing of iso_data in iso_sock_disconn()
>
> Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on
> iso_sock_release() followed by hci_abort_conn_sync().
>
> Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync")
> Signed-off-by: Pauli Virtanen <pav@iki.fi>
> ---
>
> Notes:
> The locking around iso_data and conn->hcon access looks wrong here,
> there's very likely concurrency bugs with UAF here. These should be
> fixed in separate series.
>
> net/bluetooth/iso.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
> index 2e95a153912c..babba61eb335 100644
> --- a/net/bluetooth/iso.c
> +++ b/net/bluetooth/iso.c
> @@ -837,6 +837,7 @@ 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->iso_data = NULL;
> iso_pi(sk)->conn->hcon = NULL;
> iso_conn_unlock(iso_pi(sk)->conn);
> }
Well, this was wrong as noted by Sashiko, hcon shall be detached from
conn only via iso_conn_put(), we should just drop here instead and
maybe avoid a second drop in iso_conn_free().
-> v2
--
Pauli Virtanen
^ permalink raw reply
* RE: Bluetooth: ISO: clear iso_data always when detaching conn from hcon
From: bluez.test.bot @ 2026-07-20 16:38 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <f3d8d52dcb2a5464393623a56369ea244c144460.1784559155.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 1981 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=1130974
---Test result---
Test Summary:
CheckPatch PASS 0.56 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.09 seconds
GitLint PASS 0.24 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 25.05 seconds
CheckAllWarning PASS 27.99 seconds
CheckSparse PASS 26.38 seconds
BuildKernel32 PASS 24.53 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 461.83 seconds
TestRunner_iso-tester FAIL 98.86 seconds
IncrementalBuild PASS 23.07 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_iso-tester - FAIL
Desc: Run iso-tester with test-runner
Output:
Total: 141, Passed: 134 (95.0%), Failed: 7, Not Run: 0
Failed Test Cases
ISO Disconnect - Success Timed out 2.623 seconds
ISO Reconnect - Success Timed out 1.990 seconds
ISO Reconnect Send and Receive #16 - Success Timed out 1.998 seconds
ISO Reconnect AC 6(i) - Success Timed out 2.307 seconds
ISO Reconnect AC 6(ii) - Success Timed out 1.999 seconds
ISO Broadcaster Reconnect - Success Timed out 2.731 seconds
ISO Broadcaster Receiver Defer Reconnect - Success Timed out 2.326 seconds
https://github.com/bluez/bluetooth-next/pull/462
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: hci_sync: Fix scan response data UAF
From: Chengfeng Ye @ 2026-07-20 16:47 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, Chengfeng Ye, stable
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
^ permalink raw reply related
* RE: Bluetooth: fix BT dependency for submodules
From: bluez.test.bot @ 2026-07-20 16:48 UTC (permalink / raw)
To: linux-bluetooth, iva
In-Reply-To: <20260720150919.9602-1-iva@yenya.net>
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1130992
---Test result---
Test Summary:
CheckPatch PASS 0.95 seconds
VerifyFixes PASS 0.08 seconds
VerifySignedoff PASS 0.08 seconds
GitLint PASS 0.22 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 27.63 seconds
CheckAllWarning PASS 30.42 seconds
CheckSparse PASS 29.04 seconds
BuildKernel32 PASS 35.21 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 512.13 seconds
TestRunner_l2cap-tester PASS 60.63 seconds
TestRunner_iso-tester PASS 89.18 seconds
TestRunner_bnep-tester PASS 19.06 seconds
TestRunner_mgmt-tester FAIL 213.64 seconds
TestRunner_rfcomm-tester PASS 25.85 seconds
TestRunner_sco-tester PASS 31.82 seconds
TestRunner_ioctl-tester PASS 26.32 seconds
TestRunner_mesh-tester FAIL 26.18 seconds
TestRunner_smp-tester PASS 24.30 seconds
TestRunner_userchan-tester PASS 20.34 seconds
TestRunner_6lowpan-tester PASS 23.37 seconds
IncrementalBuild PASS 26.15 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.250 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.216 seconds
Mesh - Send cancel - 2 Timed out 1.992 seconds
https://github.com/bluez/bluetooth-next/pull/463
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ] tools/iso-tester: fix GIOChannel refcounting
From: Pauli Virtanen @ 2026-07-20 18:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pauli Virtanen
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.
---
tools/iso-tester.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/tools/iso-tester.c b/tools/iso-tester.c
index 767ee0c57..fe27eaaf3 100644
--- a/tools/iso-tester.c
+++ b/tools/iso-tester.c
@@ -697,10 +697,20 @@ static void test_pre_setup(const void *test_data)
read_index_list_callback, NULL, NULL);
}
+static void io_free(void *data)
+{
+ GIOChannel *io = data;
+
+ g_io_channel_unref(io);
+}
+
static void test_post_teardown(const void *test_data)
{
struct test_data *data = tester_get_data();
+ if (data->io_queue)
+ queue_remove_all(data->io_queue, NULL, NULL, io_free);
+
mgmt_send(data->mgmt, MGMT_OP_SET_EXP_FEATURE, MGMT_INDEX_NONE,
sizeof(reset_iso_socket_param), reset_iso_socket_param,
NULL, NULL, NULL);
@@ -709,13 +719,6 @@ static void test_post_teardown(const void *test_data)
data->hciemu = NULL;
}
-static void io_free(void *data)
-{
- GIOChannel *io = data;
-
- g_io_channel_unref(io);
-}
-
static void test_data_free(void *test_data)
{
struct test_data *data = test_data;
@@ -2387,8 +2390,10 @@ static gboolean iso_disconnected(GIOChannel *io, GIOCondition cond,
data->step++;
- iso_defer_accept_bcast(data,
- parent, 0, iso_accept_cb);
+ if (!iso_defer_accept_bcast(data,
+ g_io_channel_ref(parent), 0,
+ iso_accept_cb))
+ g_io_channel_unref(parent);
}
return FALSE;
@@ -3094,15 +3099,15 @@ static void setup_connect_many(struct test_data *data, uint8_t n, uint8_t *num,
data->io_id[num[i]] = g_io_add_watch(io, G_IO_OUT, func[i],
NULL);
- if (!isodata->bcast || !data->reconnect)
- g_io_channel_unref(io);
- else if (data->io_queue)
+ if (data->io_queue)
/* For the broadcast reconnect scenario, do not
* unref channel here, to avoid closing the
* socket. All queued channels will be closed
- * by test_data_free.
+ * by test_post_teardown.
*/
queue_push_tail(data->io_queue, io);
+ else
+ g_io_channel_unref(io);
tester_print("Connect %d in progress", num[i]);
@@ -3495,6 +3500,7 @@ static gboolean iso_accept(GIOChannel *io, GIOCondition cond,
if (!iso_defer_accept(data, new_io, num, func)) {
tester_warn("Unable to accept deferred setup");
tester_test_failed();
+ g_io_channel_unref(new_io);
}
return false;
}
@@ -3724,6 +3730,7 @@ static void test_connect_close(const void *test_data)
data);
shutdown(sk, SHUT_RDWR);
+ g_io_channel_unref(io);
}
static gboolean iso_connect_wait_close_cb(GIOChannel *io, GIOCondition cond,
--
2.55.0
^ permalink raw reply related
* [PATCH v2] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: Pauli Virtanen @ 2026-07-20 18:30 UTC (permalink / raw)
To: linux-bluetooth
Cc: Pauli Virtanen, marcel, luiz.dentz, iulia.tanasescu, linux-kernel
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;
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 related
* Re: [PATCH v2] gdbus: Remove broad match rule and add proxy filter support
From: Luiz Augusto von Dentz @ 2026-07-20 18:42 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: denkenz, ofono, linux-bluetooth, cheng.jiang, quic_chezhou,
wei.deng, shuai.zhang, mengshi.wu, jinwang.li
In-Reply-To: <20260715085950.4079331-1-xiuzhuo.shang@oss.qualcomm.com>
Hi Xiuzhuo,
On Wed, Jul 15, 2026 at 4:59 AM Xiuzhuo Shang
<xiuzhuo.shang@oss.qualcomm.com> wrote:
>
> Problem
> -------
> On embedded platforms running continuous BLE scanning, bluetoothd
> eventually stalls with its D-Bus socket to dbus-daemon full. strace
> on a hung bluetoothd shows a repeating pattern:
>
> sendmsg(7, {org.bluez.Device1 PropertiesChanged}, MSG_NOSIGNAL)
> = -1 EAGAIN (Resource temporarily unavailable)
> ppoll([{fd=7, events=POLLOUT}], 1, {tv_sec=0, tv_nsec=0}) = 0 (Timeout)
>
> fd=7 never becomes writable; bluetoothd's GMainLoop remains stuck
> waiting for POLLOUT and cannot dispatch any further D-Bus events,
> making the daemon appear hung and unresponsive to commands.
>
> The backpressure chain that causes this:
> 1. BLE scanning generates high-rate PropertiesChanged(RSSI) signals
> (~400/s with typical BLE traffic).
> 2. ofono's broad path_namespace='/' match rule causes dbus-daemon to
> route all these signals to ofono even though ofono has no use for
> BLE RSSI data.
> 3. ofono's single-threaded GLib loop cannot consume them fast enough;
> undelivered messages accumulate inside dbus-daemon (457 MB
> observed after ~3 hours of scanning).
> 4. dbus-daemon, busy draining its write queue toward ofono, stops
> reading from bluetoothd's socket in time; bluetoothd's kernel
> send buffer fills up and sendmsg() returns EAGAIN.
> 5. With POLLOUT registered on fd=7, bluetoothd's GMainLoop stalls
> and can no longer send D-Bus replies or signals.
>
> Fix
> ---
> Three related changes:
>
> 1. Remove the broad type='signal',sender=<svc>,path_namespace=<path>
> match rule from g_dbus_client_new_full(). This rule was the sole
> feeder for the signal_func path in message_filter(). ofono never
> calls g_dbus_client_set_signal_watch() so signal_func is always
> NULL; the broad rule therefore served no purpose and caused
> dbus-daemon to route every bluetoothd signal to ofono.
>
> 2. Remove the now-empty match_rules GPtrArray infrastructure
> (field declaration, init, AddMatch loop, RemoveMatch loop, free).
> No match rules are added to this array any more.
>
> 3. Add a generic GDBusProxyFilterFunction callback and
> g_dbus_client_set_proxy_filter() API to GDBusClient. The filter
> is called from parse_properties() before proxy_new(), so a FALSE
> return prevents both proxy creation and per-device
> PropertiesChanged watch registration. This keeps all BlueZ-
> specific logic out of the gdbus layer.
>
> Use this in hfp_hf_bluez5.c to skip Device1 proxies for BLE
> random-address devices: ofono only needs BR/EDR (AddressType=
> 'public') devices for HFP/HSP. Skipping BLE proxies prevents
> dbus-daemon from registering per-device PropertiesChanged match
> rules for advertising peripherals and eliminates the remaining
> RSSI signal delivery to ofono.
> Together these changes prevent dbus-daemon from routing BLE
> advertising signals to ofono, breaking the backpressure chain:
> dbus-daemon memory stops growing, its write queue drains, and
> bluetoothd's send buffer clears so that sendmsg() no longer returns
> EAGAIN and the GMainLoop stall is resolved.
>
> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
> ---
> Changes in v2:
> - Drop Change 1 (BLE address-type filter in parse_properties()) per
> review feedback; BlueZ-specific logic does not belong in the gdbus
> layer.
> - Add generic GDBusProxyFilterFunction callback and
> g_dbus_client_set_proxy_filter() API to GDBusClient. The filter is
> invoked before proxy_new() so a FALSE return prevents both proxy
> creation and per-device PropertiesChanged watch registration.
> - Use the new filter in hfp_hf_bluez5.c to skip Device1 proxies for
> BLE random-address devices, keeping all BlueZ-specific logic in the
> plugin as suggested.
> - Remove now-empty match_rules GPtrArray infrastructure (field,
> init, AddMatch loop, RemoveMatch loop, free) and unused variables.
> - Link to v1:
> https://lore.kernel.org/ofono/20260710075548.1072741-1-xiuzhuo.shang@oss.qualcomm.com/
>
> gdbus/client.c | 45 +++++++++++++++++++++--------------------
> gdbus/gdbus.h | 8 ++++++++
> plugins/hfp_hf_bluez5.c | 38 ++++++++++++++++++++++++++++++++++
> 3 files changed, 69 insertions(+), 22 deletions(-)
>
> diff --git a/gdbus/client.c b/gdbus/client.c
> index 48711ae8..fa2e75c0 100644
> --- a/gdbus/client.c
> +++ b/gdbus/client.c
> @@ -46,7 +46,6 @@ struct GDBusClient {
> guint watch;
> guint added_watch;
> guint removed_watch;
> - GPtrArray *match_rules;
> DBusPendingCall *pending_call;
> DBusPendingCall *get_objects_call;
> GDBusWatchFunction connect_func;
> @@ -61,6 +60,8 @@ struct GDBusClient {
> GDBusClientFunction ready;
> void *ready_data;
> GDBusPropertyFunction property_changed;
> + GDBusProxyFilterFunction proxy_filter;
> + void *filter_user_data;
> void *user_data;
> GList *proxy_list;
> };
> @@ -943,6 +944,14 @@ static void parse_properties(GDBusClient *client, const char *path,
> return;
> }
>
> + if (client->proxy_filter) {
> + DBusMessageIter copy = *iter;
> +
> + if (!client->proxy_filter(client, path, interface,
> + ©, client->filter_user_data))
> + return;
> + }
> +
> proxy = proxy_new(client, path, interface);
> if (proxy == NULL)
> return;
> @@ -1211,7 +1220,6 @@ GDBusClient *g_dbus_client_new_full(DBusConnection *connection,
> const char *root_path)
> {
> GDBusClient *client;
> - unsigned int i;
>
> if (!connection || !service)
> return NULL;
> @@ -1232,9 +1240,6 @@ GDBusClient *g_dbus_client_new_full(DBusConnection *connection,
> client->root_path = g_strdup(root_path);
> client->connected = FALSE;
>
> - client->match_rules = g_ptr_array_sized_new(1);
> - g_ptr_array_set_free_func(client->match_rules, g_free);
> -
> client->watch = g_dbus_add_service_watch(connection, service,
> service_connect,
> service_disconnect,
> @@ -1255,14 +1260,6 @@ GDBusClient *g_dbus_client_new_full(DBusConnection *connection,
> "InterfacesRemoved",
> interfaces_removed,
> client, NULL);
> - g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
> - "sender='%s',path_namespace='%s'",
> - client->service_name, client->base_path));
> -
> - for (i = 0; i < client->match_rules->len; i++) {
> - modify_match(client->dbus_conn, "AddMatch",
> - g_ptr_array_index(client->match_rules, i));
> - }
>
> return g_dbus_client_ref(client);
> }
> @@ -1279,8 +1276,6 @@ GDBusClient *g_dbus_client_ref(GDBusClient *client)
>
> void g_dbus_client_unref(GDBusClient *client)
> {
> - unsigned int i;
> -
> if (client == NULL)
> return;
>
> @@ -1297,13 +1292,6 @@ void g_dbus_client_unref(GDBusClient *client)
> dbus_pending_call_unref(client->get_objects_call);
> }
>
> - for (i = 0; i < client->match_rules->len; i++) {
> - modify_match(client->dbus_conn, "RemoveMatch",
> - g_ptr_array_index(client->match_rules, i));
> - }
> -
> - g_ptr_array_free(client->match_rules, TRUE);
> -
> dbus_connection_remove_filter(client->dbus_conn,
> message_filter, client);
>
> @@ -1396,3 +1384,16 @@ gboolean g_dbus_client_set_proxy_handlers(GDBusClient *client,
>
> return TRUE;
> }
> +
> +gboolean g_dbus_client_set_proxy_filter(GDBusClient *client,
> + GDBusProxyFilterFunction proxy_filter,
> + void *user_data)
> +{
> + if (client == NULL)
> + return FALSE;
> +
> + client->proxy_filter = proxy_filter;
> + client->filter_user_data = user_data;
> +
> + return TRUE;
> +}
> diff --git a/gdbus/gdbus.h b/gdbus/gdbus.h
> index d99c2549..cc3c4e16 100644
> --- a/gdbus/gdbus.h
> +++ b/gdbus/gdbus.h
> @@ -347,6 +347,11 @@ typedef void (* GDBusClientFunction) (GDBusClient *client, void *user_data);
> typedef void (* GDBusProxyFunction) (GDBusProxy *proxy, void *user_data);
> typedef void (* GDBusPropertyFunction) (GDBusProxy *proxy, const char *name,
> DBusMessageIter *iter, void *user_data);
> +typedef gboolean (* GDBusProxyFilterFunction) (GDBusClient *client,
> + const char *path,
> + const char *interface,
> + DBusMessageIter *iter,
> + void *user_data);
>
> gboolean g_dbus_proxy_set_property_watch(GDBusProxy *proxy,
> GDBusPropertyFunction function, void *user_data);
> @@ -377,6 +382,9 @@ gboolean g_dbus_client_set_proxy_handlers(GDBusClient *client,
> GDBusProxyFunction proxy_removed,
> GDBusPropertyFunction property_changed,
> void *user_data);
> +gboolean g_dbus_client_set_proxy_filter(GDBusClient *client,
> + GDBusProxyFilterFunction proxy_filter,
> + void *user_data);
>
> #ifdef __cplusplus
> }
> diff --git a/plugins/hfp_hf_bluez5.c b/plugins/hfp_hf_bluez5.c
> index 5ad1674f..141dc5c4 100644
> --- a/plugins/hfp_hf_bluez5.c
> +++ b/plugins/hfp_hf_bluez5.c
> @@ -791,6 +791,43 @@ static void proxy_added(GDBusProxy *proxy, void *user_data)
> device_changed(proxy, path);
> }
>
> +static gboolean proxy_filter(GDBusClient *client, const char *path,
> + const char *interface, DBusMessageIter *iter,
> + void *user_data)
> +{
> + DBusMessageIter props, entry;
> +
> + if (g_str_equal(BLUEZ_DEVICE_INTERFACE, interface) == FALSE)
> + return TRUE;
> +
> + if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_ARRAY)
> + return TRUE;
> +
> + dbus_message_iter_recurse(iter, &props);
> +
> + while (dbus_message_iter_get_arg_type(&props) == DBUS_TYPE_DICT_ENTRY) {
> + const char *key;
> +
> + dbus_message_iter_recurse(&props, &entry);
> + dbus_message_iter_get_basic(&entry, &key);
> +
> + if (g_str_equal(key, "AddressType") == TRUE) {
> + DBusMessageIter var;
> + const char *addr_type;
> +
> + dbus_message_iter_next(&entry);
> + dbus_message_iter_recurse(&entry, &var);
> + dbus_message_iter_get_basic(&var, &addr_type);
> +
> + return !g_str_equal(addr_type, "random");
> + }
> +
> + dbus_message_iter_next(&props);
> + }
> +
> + return TRUE;
> +}
> +
> static void property_changed(GDBusProxy *proxy, const char *name,
> DBusMessageIter *iter, void *user_data)
> {
> @@ -844,6 +881,7 @@ static int hfp_init(void)
> g_dbus_client_set_connect_watch(bluez, connect_handler, NULL);
> g_dbus_client_set_proxy_handlers(bluez, proxy_added, NULL,
> property_changed, NULL);
> + g_dbus_client_set_proxy_filter(bluez, proxy_filter, NULL);
I don't really follow; would this register a proxy filter and
automatically remove it on the first match of an AddressType=random??
Sounds not really useful to me, what is the difference if we don't use
set_proxy_filter above?
>
> ofono_handsfree_audio_ref();
>
> --
> 2.43.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: Bluetooth: hci_sync: Fix scan response data UAF
From: bluez.test.bot @ 2026-07-20 18:55 UTC (permalink / raw)
To: linux-bluetooth, nicoyip.dev
In-Reply-To: <20260720164738.2921802-1-nicoyip.dev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1131053
---Test result---
Test Summary:
CheckPatch PASS 0.76 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 26.83 seconds
CheckAllWarning PASS 29.18 seconds
CheckSparse PASS 28.05 seconds
BuildKernel32 PASS 26.12 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 494.85 seconds
TestRunner_l2cap-tester PASS 59.19 seconds
TestRunner_iso-tester PASS 77.64 seconds
TestRunner_bnep-tester PASS 19.49 seconds
TestRunner_mgmt-tester FAIL 209.24 seconds
TestRunner_rfcomm-tester PASS 25.07 seconds
TestRunner_sco-tester PASS 31.10 seconds
TestRunner_ioctl-tester PASS 25.70 seconds
TestRunner_mesh-tester FAIL 26.02 seconds
TestRunner_smp-tester PASS 22.95 seconds
TestRunner_userchan-tester PASS 20.46 seconds
TestRunner_6lowpan-tester PASS 25.12 seconds
IncrementalBuild PASS 25.36 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.236 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.584 seconds
Mesh - Send cancel - 2 Timed out 1.989 seconds
https://github.com/bluez/bluetooth-next/pull/464
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH BlueZ 0/2] Don't auto-bond on reactive GATT security elevation
From: Luiz Augusto von Dentz @ 2026-07-20 18:58 UTC (permalink / raw)
To: Philipp Dunkel; +Cc: linux-bluetooth
In-Reply-To: <20260718194230.35959-1-pip@pipobscure.com>
Hi Philipp,
On Sat, Jul 18, 2026 at 3:43 PM Philipp Dunkel <pip@pipobscure.com> wrote:
>
> bluetoothd probes every freshly connected LE peer as a GATT client
> through its built-in profiles (battery, mcp, ...). When such a probe
> reads a characteristic the peer has protected, the peer answers with
> Insufficient Authentication (0x05), and change_security() reacts by
> raising BT_SECURITY on the ATT socket. On an unbonded LE link that
> starts SMP pairing, so the user is shown a pairing prompt for a device
> that merely came into range -- a bond nobody requested, logged as a
> device_bonding_complete() bond with a (nil) requestor.
You will need to determine which plugins are discovering attributes
that may require encryption and disable them since they won't function
otherwise and are probably just dead weight at that point. Also I
don't think there is an easy policy to determine the roles of each
side since "client" doesn't necessarily mean central, nor does
peripheral necessarily mean server.
> The existing opt-out does not help: change_security() only bails when
> chan->sec_level != BT_ATT_SECURITY_AUTO, but sec_level is recorded for
> BT_ATT_LOCAL channels only, so an L2CAP/LE channel stays at AUTO for its
> whole lifetime and always elevates.
>
> Patch 1 adds bt_att_set_no_auto_sec(), a per-bt_att flag that makes
> change_security() refuse to elevate, and sets it from gatt_client_init()
> for any link that is neither bonded nor in a requested bonding.
> In-progress Pair() and already-bonded devices keep their existing
> elevation paths untouched.
>
> Patch 2 adds a unit test: it arms AUTO security and then forbids
> elevation, asserting the auth error is delivered to the caller with no
> retry on the wire. Without patch 1 the client retries and the test
> aborts on the unexpected Read Request.
>
> Tested against Android (Galaxy Z Flip 4), iOS (iPhone) and macOS
> (MacBook): each connects and is probed with no unsolicited pairing
> prompt, while explicit pairing continues to work.
Why are you connecting in the first place? Who is advertising?
Actually if you end up with an encrypted link, that's a win in terms
of security, so why would it be a bad thing?
> Both patches were developed with the assistance of an AI model
> (Claude Opus 4.8), disclosed per-patch with an Assisted-by: trailer.
> Every line was reviewed by me and the result was built, run and tested
> on the hardware above -- behaviour observed, not inferred.
>
> Philipp Dunkel (2):
> shared/att: don't auto-bond on reactive elevation
> unit/test-gatt: cover no-auto-sec on auth error
>
> src/device.c | 13 +++++++++++++
> src/shared/att.c | 20 ++++++++++++++++++++
> src/shared/att.h | 1 +
> unit/test-gatt.c | 28 ++++++++++++++++++++++++++++
> 4 files changed, 62 insertions(+)
>
> --
> 2.55.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v2] Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v1()
From: Doruk Tan Ozturk @ 2026-07-20 19:13 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Marcel Holtmann, Amitkumar Karwar,
Neeraj Kale
Cc: Paul Menzel, linux-bluetooth, linux-kernel, stable,
Doruk Tan Ozturk
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",
+ 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
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: ISO: fix UAF on socket close before shutdown completes
From: Luiz Augusto von Dentz @ 2026-07-20 19:37 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth, marcel, iulia.tanasescu, linux-kernel
In-Reply-To: <4d96c545ad1a2fed02440a3478905853286aa0c7.1784571683.git.pav@iki.fi>
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.
> 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 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
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