* Re: [PATCH] Bluetooth: btintel: Fix insufficient skb length check in btintel_print_fseq_info()
From: Luiz Augusto von Dentz @ 2026-05-14 17:35 UTC (permalink / raw)
To: Quan Sun; +Cc: linux-bluetooth, kiran.k, marcel
In-Reply-To: <20260514164913.3123671-1-2022090917019@std.uestc.edu.cn>
Hi,
On Thu, May 14, 2026 at 12:49 PM Quan Sun
<2022090917019@std.uestc.edu.cn> wrote:
>
> The length check at the top of btintel_print_fseq_info() verifies
> that the skb has at least 66 bytes (sizeof(u32) * 16 + 2), but the
> function actually consumes 74 bytes:
>
> 2 calls to skb_pull_data(skb, 1) = 2 bytes
> 18 calls to skb_pull_data(skb, 4) = 72 bytes
>
> When the firmware returns a packet of exactly 66 bytes, the last two
> skb_pull_data(skb, 4) calls return NULL, which is then passed directly
> to get_unaligned_le32(), resulting in a NULL pointer dereference.
>
> Fix the length check to account for all 74 bytes actually consumed:
> sizeof(u32) * 16 + 2 -> sizeof(u32) * 18 + 2
>
> Fixes: a7ba218a44aa ("Bluetooth: btintel: Print Firmware Sequencer information")
> Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
> ---
> drivers/bluetooth/btintel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
> index dcaaa4ca02b99..114a8beeab92d 100644
> --- a/drivers/bluetooth/btintel.c
> +++ b/drivers/bluetooth/btintel.c
> @@ -3356,7 +3356,7 @@ void btintel_print_fseq_info(struct hci_dev *hdev)
> return;
> }
>
> - if (skb->len < (sizeof(u32) * 16 + 2)) {
> + if (skb->len < (sizeof(u32) * 18 + 2)) {
Or we stop doing this manually and the check the return of
skb_pull_data, that way we garantee we don't use its returns without
checking if it return NULL, which is the whole point in using
skb_pull_data otherwise we had just used skb_pull.
> bt_dev_dbg(hdev, "Malformed packet of length %u received",
> skb->len);
> kfree_skb(skb);
> --
> 2.43.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] Bluetooth: btmtk: Fix FUNC_CTRL parsing for devices with zero-length payloads
From: Shivam Kalra via B4 Relay @ 2026-05-14 17:48 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, Tristan Madani
Cc: Luiz Augusto von Dentz, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Shivam Kalra
From: Shivam Kalra <shivamkalra98@zohomail.in>
Commit 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length
before struct access") added strict SKB length checks to prevent OOB
memory reads when parsing WMT events.
However, when enabling the protocol (flag = 0), the MT7922 returns a WMT
event with a zero-length payload (skb->len == 7), omitting the 2-byte
status field entirely.
The strict sizeof() check unconditionally enforced the presence of the
status field for all BTMTK_WMT_FUNC_CTRL events. This caused the driver
to reject these payload-less responses with -EINVAL, failing Bluetooth
initialization ("Failed to send wmt func ctrl (-22)").
Fix this by making skb_pull_data() conditional: if the status payload is
present, parse it as before; if omitted, default to BTMTK_WMT_ON_UNDONE.
This restores the pre-regression initialization behavior while
maintaining the memory safety bounds of the previous patch.
Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221511
Cc: stable@vger.kernel.org
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
---
Tested on a laptop with a single MediaTek MT7922 (USB ID 0489:e0e0)
Bluetooth controller. Before this patch, Bluetooth initialization failed
with "Failed to send wmt func ctrl (-22)" on every boot. After applying
this patch, initialization succeeds reliably.
This regression is also reported by other users on the kernel bug
tracker [1].
Note: btmtksdio.c and btmtkuart.c have similar FUNC_CTRL parsing code
but were not modified by the original commit 634a4408c061, so they are
not affected by this regression and do not require changes.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=221511
---
drivers/bluetooth/btmtk.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index f70c1b0f8990..026e5a76b086 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -717,19 +717,19 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
status = BTMTK_WMT_PATCH_DONE;
break;
case BTMTK_WMT_FUNC_CTRL:
- if (!skb_pull_data(data->evt_skb,
- sizeof(wmt_evt_funcc->status))) {
- err = -EINVAL;
- goto err_free_skb;
- }
-
- wmt_evt_funcc = (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
- if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
- status = BTMTK_WMT_ON_DONE;
- else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
- status = BTMTK_WMT_ON_PROGRESS;
- else
+ if (skb_pull_data(data->evt_skb,
+ sizeof(wmt_evt_funcc->status))) {
+ wmt_evt_funcc =
+ (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
+ if (be16_to_cpu(wmt_evt_funcc->status) == 0x404)
+ status = BTMTK_WMT_ON_DONE;
+ else if (be16_to_cpu(wmt_evt_funcc->status) == 0x420)
+ status = BTMTK_WMT_ON_PROGRESS;
+ else
+ status = BTMTK_WMT_ON_UNDONE;
+ } else {
status = BTMTK_WMT_ON_UNDONE;
+ }
break;
case BTMTK_WMT_PATCH_DWNLD:
if (wmt_evt->whdr.flag == 2)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260514-bluetooh-fix-mt7922-92bbbeff229b
Best regards,
--
Shivam Kalra <shivamkalra98@zohomail.in>
^ permalink raw reply related
* Re: [PATCH BlueZ v5 00/16] Functional/integration testing
From: patchwork-bot+bluetooth @ 2026-05-14 17:50 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <cover.1778688966.git.pav@iki.fi>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 13 May 2026 19:17:17 +0300 you wrote:
> Add framework for writing tests simulating "real" environments where
> BlueZ and other parts of the stack run on different virtual machine
> hosts that communicate with each other.
>
> *** v5 ***
>
> https://github.com/pv/bluez/compare/func-test-v4-r..func-test-v5
>
> [...]
Here is the summary with links:
- [BlueZ,v5,01/16] emulator: btvirt: check pkt lengths, don't get stuck on malformed
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e19c771841e9
- [BlueZ,v5,02/16] emulator: btvirt: allow specifying where server unix sockets are made
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=5ee43f9993dd
- [BlueZ,v5,03/16] emulator: btvirt: support SCO data packets
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=cc077e4a12dd
- [BlueZ,v5,04/16] emulator: btdev: clear more state on Reset
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=f1a303e1d07a
- [BlueZ,v5,05/16] test-runner: enable path argument for --unix
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=ff2ecb82e4c3
- [BlueZ,v5,06/16] test-runner: Add -o/--option option
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=82c635c879bf
- [BlueZ,v5,07/16] test-runner: allow source tree root for -k
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=1929b3a99d2f
- [BlueZ,v5,08/16] test-runner: use virtio-serial for implementing -u device forwarding
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=908c14fc3abb
- [BlueZ,v5,09/16] doc: enable CONFIG_VIRTIO_CONSOLE in tester config
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=7856de4d69d6
- [BlueZ,v5,10/16] doc: enable KVM paravirtualization & clock support in tester kernel config
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=48cb22a572c7
- [BlueZ,v5,11/16] doc: add functional/integration testing documentation
(no matching commit)
- [BlueZ,v5,12/16] test: add functional/integration testing framework
(no matching commit)
- [BlueZ,v5,13/16] build: add functional testing target
(no matching commit)
- [BlueZ,v5,14/16] test: functional: impose Python code formatting
(no matching commit)
- [BlueZ,v5,15/16] test: functional: add some Agent1 interface tests
(no matching commit)
- [BlueZ,v5,16/16] test: functional: add basic obex file transfer tests
(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 net-next v2 0/6] Bluetooth: convert remaining bluetooth socket families to getsockopt_iter
From: Luiz Augusto von Dentz @ 2026-05-14 17:51 UTC (permalink / raw)
To: Breno Leitao
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, linux-bluetooth,
linux-kernel, netdev, linux-kselftest
In-Reply-To: <20260512-getsock_three-v2-0-30b7b22ef14c@debian.org>
Hi Breno,
On Tue, May 12, 2026 at 7:12 AM Breno Leitao <leitao@debian.org> wrote:
>
> Continue the conversion to .getsockopt_iter for the Bluetooth socket
> families: hci_sock, ISO, RFCOMM, SCO and L2CAP. The first patch is a
> small precursor that fixes a long-standing 1-byte put_user write in
> hci_sock_getsockopt_old() so the subsequent conversion stays mechanical.
>
> The riskiest change in this series is the SCO BT_CODEC conversion: it
> is the only one that drops an open-coded ptr cursor in favour of
> relying on iter_out advancing naturally on every copy_to_iter() call.
> Every other socket option is a near-mechanical s/copy_to_user/
> copy_to_iter/ rewrite, but BT_CODEC walks a variable-length list of
> codecs + capabilities and previously tracked its own write offset by
> hand. Getting the cursor semantics wrong here would silently truncate
> or misalign user-visible codec data.
>
> For more context about the motivation for this change, please check
> commit 67fab22a7ad ("net: add getsockopt_iter callback to proto_ops")
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - rebase the tree on top of bluetooth-next.
> - Remove the selftest, which was mixing network and bluetooth together.
> - Link to v1: https://patch.msgid.link/20260511-getsock_three-v1-0-1461fa8786ab@debian.org
>
> To: Marcel Holtmann <marcel@holtmann.org>
> To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> Breno Leitao (6):
> Bluetooth: hci_sock: write the full optval for getsockopt
> Bluetooth: hci_sock: convert to getsockopt_iter
> Bluetooth: ISO: convert to getsockopt_iter
> Bluetooth: RFCOMM: convert to getsockopt_iter
> Bluetooth: L2CAP: convert to getsockopt_iter
> Bluetooth: SCO: convert to getsockopt_iter
>
> net/bluetooth/hci_sock.c | 26 +++++++++++--------
> net/bluetooth/iso.c | 27 ++++++++++----------
> net/bluetooth/l2cap_sock.c | 61 +++++++++++++++++++++++++++------------------
> net/bluetooth/rfcomm/sock.c | 30 ++++++++++++----------
> net/bluetooth/sco.c | 59 ++++++++++++++++++++++---------------------
> 5 files changed, 114 insertions(+), 89 deletions(-)
> ---
> base-commit: c2f0079e8c42fd6814c8d6b1491e3ce0a0e3b3fa
> change-id: 20260511-getsock_three-d0d7f1b2629e
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
There are some comments from sashiko on this:
https://sashiko.dev/#/patchset/20260512-getsock_three-v2-0-30b7b22ef14c%40debian.org
Now Im not sure the truncating is actually used by our tools, but that
sounds like it could break userspace if we don't check properly, or
have you already done this for other socket families and it was
considered to be ok?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: btintel: Fix insufficient skb length check in btintel_print_fseq_info()
From: Quan Sun @ 2026-05-14 18:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, kiran.k, marcel
In-Reply-To: <CABBYNZJ+qJ4RfRz3W9Uf7Rs5kmyJfN_oqD5o8B6_eLLja8nXpg@mail.gmail.com>
Hi,
On 2026/5/15 1:35, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Thu, May 14, 2026 at 12:49 PM Quan Sun
> <2022090917019@std.uestc.edu.cn> wrote:
>>
>> The length check at the top of btintel_print_fseq_info() verifies
>> that the skb has at least 66 bytes (sizeof(u32) * 16 + 2), but the
>> function actually consumes 74 bytes:
>>
>> 2 calls to skb_pull_data(skb, 1) = 2 bytes
>> 18 calls to skb_pull_data(skb, 4) = 72 bytes
>>
>> When the firmware returns a packet of exactly 66 bytes, the last two
>> skb_pull_data(skb, 4) calls return NULL, which is then passed directly
>> to get_unaligned_le32(), resulting in a NULL pointer dereference.
>>
>> Fix the length check to account for all 74 bytes actually consumed:
>> sizeof(u32) * 16 + 2 -> sizeof(u32) * 18 + 2
>>
>> Fixes: a7ba218a44aa ("Bluetooth: btintel: Print Firmware Sequencer information")
>> Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
>> ---
>> drivers/bluetooth/btintel.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
>> index dcaaa4ca02b99..114a8beeab92d 100644
>> --- a/drivers/bluetooth/btintel.c
>> +++ b/drivers/bluetooth/btintel.c
>> @@ -3356,7 +3356,7 @@ void btintel_print_fseq_info(struct hci_dev *hdev)
>> return;
>> }
>>
>> - if (skb->len < (sizeof(u32) * 16 + 2)) {
>> + if (skb->len < (sizeof(u32) * 18 + 2)) {
>
> Or we stop doing this manually and the check the return of
> skb_pull_data, that way we garantee we don't use its returns without
> checking if it return NULL, which is the whole point in using
> skb_pull_data otherwise we had just used skb_pull.
>
>> bt_dev_dbg(hdev, "Malformed packet of length %u received",
>> skb->len);
>> kfree_skb(skb);
>> --
>> 2.43.0
>>
>
>
You are right. I will refactor the function to check the return value of
each skb_pull_data() call to make it more robust.
^ permalink raw reply
* RE: Bluetooth: btmtk: Fix FUNC_CTRL parsing for devices with zero-length payloads
From: bluez.test.bot @ 2026-05-14 18:21 UTC (permalink / raw)
To: linux-bluetooth, shivamkalra98
In-Reply-To: <20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in>
[-- Attachment #1: Type: text/plain, Size: 552 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/bluetooth/btmtk.c:717
error: drivers/bluetooth/btmtk.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v2] Bluetooth: btintel_pcie: Fix incorrect MAC access programming
From: Kiran K @ 2026-05-14 19:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: ravishankar.srivatsa, chethan.tumkur.narayan, Kiran K
btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access()
were programming STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ in addition to
the MAC_ACCESS_REQ handshake. These bits are not part of the host
MAC-access handshake on the supported parts; the driver was
programming them incorrectly. Drop the writes so the register update
contains only the bits the controller actually consumes.
Fixes: b9465e6670a2 ("Bluetooth: btintel_pcie: Read hardware exception data")
Signed-off-by: Kiran K <kiran.k@intel.com>
---
Changes in v2:
- Reworded commit message and subject; describe the bits as the driver
programming the hardware incorrectly.
- Added Fixes: tag.
- Skip the FUNC_CTRL register write when MAC_ACCESS_REQ is already in
the desired state in both get/release paths.
v1: https://lore.kernel.org/linux-bluetooth/20260511133932.1217624-1-kiran.k@intel.com/
drivers/bluetooth/btintel_pcie.c | 20 ++++++--------------
drivers/bluetooth/btintel_pcie.h | 3 ---
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
index fda474406003..eba563b66090 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -594,12 +594,10 @@ static int btintel_pcie_get_mac_access(struct btintel_pcie_data *data)
reg = btintel_pcie_rd_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG);
- reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS;
- reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ;
- if ((reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS) == 0)
+ if (!(reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ)) {
reg |= BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ;
-
- btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
+ btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
+ }
do {
reg = btintel_pcie_rd_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG);
@@ -619,16 +617,10 @@ static void btintel_pcie_release_mac_access(struct btintel_pcie_data *data)
reg = btintel_pcie_rd_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG);
- if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ)
+ if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ) {
reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ;
-
- if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS)
- reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS;
-
- if (reg & BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ)
- reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ;
-
- btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
+ btintel_pcie_wr_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG, reg);
+ }
}
static void *btintel_pcie_copy_tlv(void *dest, enum btintel_pcie_tlv_type type,
diff --git a/drivers/bluetooth/btintel_pcie.h b/drivers/bluetooth/btintel_pcie.h
index 2db85f71b2f8..7fc8c46ed689 100644
--- a/drivers/bluetooth/btintel_pcie.h
+++ b/drivers/bluetooth/btintel_pcie.h
@@ -34,9 +34,6 @@
#define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS (BIT(20))
#define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ (BIT(21))
-/* Stop MAC Access disconnection request */
-#define BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS (BIT(22))
-#define BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ (BIT(23))
#define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_STS (BIT(28))
#define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_DISCON (BIT(29))
--
2.53.0
^ permalink raw reply related
* RE: Bluetooth: btintel: Fix insufficient skb length check in btintel_print_fseq_info()
From: bluez.test.bot @ 2026-05-14 18:47 UTC (permalink / raw)
To: linux-bluetooth, 2022090917019
In-Reply-To: <20260514164913.3123671-1-2022090917019@std.uestc.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1537 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=1094909
---Test result---
Test Summary:
CheckPatch PASS 0.53 seconds
GitLint FAIL 0.23 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 24.46 seconds
CheckAllWarning PASS 27.38 seconds
CheckSparse PASS 26.10 seconds
BuildKernel32 PASS 24.20 seconds
TestRunnerSetup PASS 539.18 seconds
IncrementalBuild PASS 23.25 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: btintel: Fix insufficient skb length check in btintel_print_fseq_info()
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (82>80): "Bluetooth: btintel: Fix insufficient skb length check in btintel_print_fseq_info()"
https://github.com/bluez/bluetooth-next/pull/191
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ v1] test-rap: Fix gatt_ccc_read_cb on big-endian
From: Luiz Augusto von Dentz @ 2026-05-14 19:04 UTC (permalink / raw)
To: linux-bluetooth
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1367 bytes --]
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reading CCC values shall return little-endian 16 bits, not native
format.
---
unit/test-rap.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/unit/test-rap.c b/unit/test-rap.c
index 4ca4a715edff..dce592187426 100644
--- a/unit/test-rap.c
+++ b/unit/test-rap.c
@@ -253,8 +253,7 @@ static void gatt_ccc_read_cb(struct gatt_db_attribute *attrib,
struct ccc_state *ccc;
uint16_t handle;
uint8_t ecode = 0;
- const uint8_t *value = NULL;
- size_t len = 0;
+ uint16_t value = 0;
handle = gatt_db_attribute_get_handle(attrib);
@@ -264,11 +263,11 @@ static void gatt_ccc_read_cb(struct gatt_db_attribute *attrib,
goto done;
}
- len = sizeof(ccc->value);
- value = (void *) &ccc->value;
+ value = cpu_to_le16(ccc->value);
done:
- gatt_db_attribute_read_result(attrib, id, ecode, value, len);
+ gatt_db_attribute_read_result(attrib, id, ecode, (void *)&value,
+ sizeof(value));
}
static void ras_attached(struct bt_rap *rap, void *user_data)
@@ -528,7 +527,7 @@ static void test_server(const void *user_data)
RAS_FIND_INFO
/*
- * RAS/SR/RCO/BV-01-C – Characteristic Read: RAS Features
+ * RAS/SR/RCO/BV-01-C – Characteristic Read: RAS Features
*
* ATT: Read Request (0x0a) len 2
* Handle: 0x0003 (RAS Features value handle)
--
2.53.0
^ permalink raw reply related
* [PATCH BlueZ v2] test-rap: Fix gatt_ccc_read_cb on big-endian
From: Luiz Augusto von Dentz @ 2026-05-14 19:05 UTC (permalink / raw)
To: linux-bluetooth
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1364 bytes --]
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reading CCC values shall return little-endian 16 bits, not native
format.
---
unit/test-rap.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/unit/test-rap.c b/unit/test-rap.c
index 4ca4a715edff..22bc2671bf46 100644
--- a/unit/test-rap.c
+++ b/unit/test-rap.c
@@ -253,8 +253,7 @@ static void gatt_ccc_read_cb(struct gatt_db_attribute *attrib,
struct ccc_state *ccc;
uint16_t handle;
uint8_t ecode = 0;
- const uint8_t *value = NULL;
- size_t len = 0;
+ uint16_t value = 0;
handle = gatt_db_attribute_get_handle(attrib);
@@ -264,11 +263,11 @@ static void gatt_ccc_read_cb(struct gatt_db_attribute *attrib,
goto done;
}
- len = sizeof(ccc->value);
- value = (void *) &ccc->value;
+ value = cpu_to_le16(ccc->value);
done:
- gatt_db_attribute_read_result(attrib, id, ecode, value, len);
+ gatt_db_attribute_read_result(attrib, id, ecode, (void *)&value,
+ sizeof(value));
}
static void ras_attached(struct bt_rap *rap, void *user_data)
@@ -528,7 +527,7 @@ static void test_server(const void *user_data)
RAS_FIND_INFO
/*
- * RAS/SR/RCO/BV-01-C – Characteristic Read: RAS Features
+ * RAS/SR/RCO/BV-01-C Characteristic Read: RAS Features
*
* ATT: Read Request (0x0a) len 2
* Handle: 0x0003 (RAS Features value handle)
--
2.53.0
^ permalink raw reply related
* Bluetooth: HCI Create Connection issues default page-scan parameters (R2, clock_offset=0) instead of values from inquiry cache, causes Page Timeout on BR/EDR audio device
From: Jacob Mills @ 2026-05-14 19:10 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 9490 bytes --]
Hi,
Filing this for a 100%-reproducible BR/EDR pairing failure on a recent
Fedora kernel against a 2015-era audio speaker, with btmon evidence
pointing at the kernel's HCI Create Connection path ignoring
inquiry-cache page parameters. The same physical hardware pairs the same
speaker successfully on Windows.
SUMMARY
-------
When pairing a BR/EDR-only audio device that advertises Page Scan
Repetition Mode R1 with a non-zero clock offset, the kernel issues HCI
Create Connection with default values (R2, clock_offset=0). The page
never reaches the remote device and Connect Complete returns with status
Page Timeout (0x04) after the default 5.12s page timeout. Pairing fails
every time. The inquiry that immediately preceded the pair attempt was
observed by the kernel (HCI Event #3 below) and contained the correct
page parameters, so the data was available to the host stack -- it just
was not used in the subsequent Create Connection.
AFFECTED SYSTEM
---------------
Distribution Fedora 44
Kernel 7.0.6-200.fc44.x86_64
linux-firmware 20260410-1.fc44
BlueZ 5.86-4.fc44 (bluetoothd and bluetoothctl)
Controller MediaTek MT7922 (BlueZ manufacturer id 0x001d / 29)
USB ID 0489:e10d (Foxconn / Hon Hai), bcdDevice 0.01
Combo card (BT + Wi-Fi on shared antennas; Wi-Fi was
on 5 GHz at time of failure; also reproduces with
Wi-Fi disabled)
Controller MAC D8:B3:2F:44:DC:DE
Remote device Edifier Luna Eclipse HD (e25HD) powered speaker
(BR/EDR-only, A2DP Sink + AVRCP, manuf-id "Fihonest")
Remote MAC 40:EF:4C:E0:B6:7B
Three kernels are installed locally; a regression test on
6.19.10-300.fc44 has not yet been run. Happy to do that and follow up.
REPRODUCIBILITY
---------------
100% reproducible on this kernel/firmware/hardware combination across:
* bluetooth.service restart
* modprobe -r btusb && modprobe btusb (full firmware reload, confirmed
by matching "usbcore: deregistering/registered new interface driver
btusb" pair in dmesg)
* bluetoothctl power off/on (HCI Reset)
* USB autosuspend disabled
(echo on > /sys/bus/usb/devices/1-6/power/control)
* Wi-Fi radio disabled (rules out MT7922 BT/WiFi antenna coex)
* Fresh 60-second speaker power cycle
* Fresh bond state on the laptop (no on-disk bond record)
The Linux side discovers the speaker reliably via `scan bredr` at strong
signal (-55 to -58 dBm). Only the page-following-pair fails.
REPRODUCER
----------
In a single bluetoothctl session, with the speaker freshly power-cycled
and in BT input mode (solid blue LED), no other host bonded to the speaker:
[bluetoothctl]# scan bredr
... [NEW] Device 40:EF:4C:E0:B6:7B EDIFIER Luna Eclipse HD
... [CHG] Device 40:EF:4C:E0:B6:7B RSSI: 0xffffffc8 (-56)
[bluetoothctl]# scan off
[bluetoothctl]# pair 40:EF:4C:E0:B6:7B
Attempting to pair with 40:EF:4C:E0:B6:7B
Failed to pair: org.bluez.Error.ConnectionAttemptFailed
The same outcome occurs with `connect` (post-bond) -- both surface as
the same HCI Page Timeout underneath.
THE BUG, FROM BTMON
-------------------
The relevant excerpt (full snoop file attached):
> HCI Event: Extended Inquiry Result (0x2f) plen 255 #3 35.314602
Num responses: 1
Address: 40:EF:4C:E0:B6:7B
Page scan repetition mode: R1 (0x01) <-- speaker advertises R1
Class: 0x240428 (Audio/Video, HiFi Audio Device)
Clock offset: 0x3f03 <-- non-zero, valid
RSSI: -58 dBm (0xc6)
Name (complete): EDIFIER Luna Eclipse HD
Service UUIDs: A2DP Sink/Source, AVRCP Target/Controller
[ ~12s of `scan off`, MGMT Add Device, MGMT Pair Device ]
< HCI Command: Create Connection (0x01|0x0005) plen 13 #11 47.576809
Address: 40:EF:4C:E0:B6:7B
Packet type: 0xcc18
Page scan repetition mode: R2 (0x02) <-- kernel uses R2,
ignoring cache R1
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000 <-- kernel uses 0,
ignoring cache 0x3f03
Role switch: Allow peripheral (0x01)
> HCI Event: Command Status (0x0f) plen 4 #12 47.577608
Create Connection (0x01|0x0005) ncmd 1
Status: Success (0x00)
> HCI Event: Connect Complete (0x03) plen 11 #13 52.698868
Status: Page Timeout (0x04)
Address: 40:EF:4C:E0:B6:7B
Link type: ACL (0x01)
<-- 5.122s after
Create Connection
<-- = default Page Timeout
(0x2000 slots)
The kernel issued Create Connection 12 seconds after it observed the EIR
for this address. The inquiry cache entry should still have been valid
(default eviction is 60s). Either the cache is not being read on this
code path, the inquiry result is not populating the cache, or the cached
PageScanRepetitionMode / clock_offset fields are not being plumbed into
hci_acl_create_connection() (or equivalent).
For a device using R1 (1.28s page-scan-window cycle) the host-side hint
should reflect that so the controller can size its page train timing
appropriately; pairing with default R2 + null clock offset against an R1
device with a non-zero clock offset means the page train is misaligned
and the page misses entirely within the 5.12s window. On Windows, with
the same physical controller, pairing succeeds -- so Windows clearly
does plumb the inquiry-result page parameters into its page command.
SURFACE-LEVEL ERRORS THIS PRODUCES
----------------------------------
Depending on call site, BlueZ-userspace remaps the underlying HCI Page
Timeout (status 0x04) to different D-Bus errors, which can mislead
triage:
bluetoothctl pair -> org.bluez.Error.ConnectionAttemptFailed
bluetoothctl connect -> org.bluez.Error.Failed
br-connection-page-timeout
bluetoothd (audio path) -> avdtp_connect_cb() connect to
40:EF:4C:E0:B6:7B: Host is down (112)
All three are the same HCI Page Timeout under the hood.
WHAT WAS RULED OUT
------------------
Speaker hardware OK -- pairs with other devices, pairs on
Windows on the same physical host
MT7922 controller hardware OK -- works on Windows; BR/EDR scan finds
the speaker at -55 to -58 dBm
Stale kernel / firmware No -- both current (linux-firmware
20260410, kernel 7.0.6)
Bond conflict / stale key No -- empty /var/lib/bluetooth/.../<dev>
Other host hogging link No -- confirmed no other paired/connected
device
USB autosuspend on btusb No -- power/control: on,
runtime_status: active
Wi-Fi/BT antenna coex No -- fails identically with `nmcli radio
wifi off`
Stale BlueZ device cache No -- persists after `bluetoothctl remove`,
fresh discovery, full daemon restart
Stale kernel HCI state No -- persists after modprobe -r/+ btusb
Discovery transport (LE) Not it -- explicitly using `scan bredr`,
speaker appears reliably
RELATED CONTROLLER QUIRK IN DMESG (probably unrelated)
------------------------------------------------------
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
advertised, but not supported.
This is a known MT7922 firmware quirk for ESCO setup and would not
affect BR/EDR ACL paging. Listing only in case it is relevant.
ATTACHMENTS
-----------
bt.snoop -- full btmon capture covering the failing pair attempt
(sudo btmon -w /tmp/bt.snoop, captured during
`bluetoothctl scan bredr ; pair 40:EF:4C:E0:B6:7B`).
OPEN QUESTION FOR MAINTAINERS
-----------------------------
Is hci_create_connection() (or whichever code path the kernel's
mgmt_pair_device ends up calling) expected to look up the inquiry cache
for the target BD_ADDR and pull PageScanRepetitionMode / clock_offset
from there? Or is the userspace MGMT Pair Device (0x0019) opcode
expected to carry these parameters?
If the latter, this could equally be a BlueZ userspace bug not
forwarding inquiry data into the mgmt call. The trace above shows the
inquiry data reaching the kernel; whether it survives into the
create-connection path is the open question.
Have a great day,
Jacob Mills
[-- Attachment #2: bt.snoop --]
[-- Type: application/octet-stream, Size: 1818 bytes --]
^ permalink raw reply
* [bluez/bluez] e19c77: emulator: btvirt: check pkt lengths, don't get stu...
From: Pauli Virtanen @ 2026-05-14 19:10 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: e19c771841e9017326103a8d8e8139b2374ffe19
https://github.com/bluez/bluez/commit/e19c771841e9017326103a8d8e8139b2374ffe19
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M emulator/server.c
Log Message:
-----------
emulator: btvirt: check pkt lengths, don't get stuck on malformed
Don't try to parse packet before whole header is received.
If received data has unknown packet type, reset buffer so that we don't
get stuck.
Commit: 5ee43f9993ddb6f42a281b513885d9f0eb9f9a05
https://github.com/bluez/bluez/commit/5ee43f9993ddb6f42a281b513885d9f0eb9f9a05
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M emulator/main.c
Log Message:
-----------
emulator: btvirt: allow specifying where server unix sockets are made
Make --server to take optional path name where to create the various
server sockets.
Commit: cc077e4a12dd4d7e3eeeacc1a658416d105f7f39
https://github.com/bluez/bluez/commit/cc077e4a12dd4d7e3eeeacc1a658416d105f7f39
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M emulator/server.c
Log Message:
-----------
emulator: btvirt: support SCO data packets
Support also SCO data packets in btvirt.
Commit: f1a303e1d07a715db6d7cadcf757e02f41c0468b
https://github.com/bluez/bluez/commit/f1a303e1d07a715db6d7cadcf757e02f41c0468b
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M emulator/btdev.c
Log Message:
-----------
emulator: btdev: clear more state on Reset
On controller Reset command, initialize most fields in struct btdev to
zero, similarly to the state just after btdev_create().
This excludes some fields like command bitmasks, which hciemu may have
adjusted.
To make this easier, add struct_group() macro similar to what kernel
uses.
Commit: ff2ecb82e4c38849112aebe0ac9b27af03a2284d
https://github.com/bluez/bluez/commit/ff2ecb82e4c38849112aebe0ac9b27af03a2284d
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M tools/test-runner.c
Log Message:
-----------
test-runner: enable path argument for --unix
Allow specifying the path for the controller socket to be used.
Commit: 82c635c879bf66b6efe36d4efb184c02d9c15dc1
https://github.com/bluez/bluez/commit/82c635c879bf66b6efe36d4efb184c02d9c15dc1
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M tools/test-runner.c
Log Message:
-----------
test-runner: Add -o/--option option
Allow passing arbitrary arguments to QEMU.
Commit: 1929b3a99d2f2149fd9fb0e2cb473fcdce4da63a
https://github.com/bluez/bluez/commit/1929b3a99d2f2149fd9fb0e2cb473fcdce4da63a
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M tools/test-runner.c
Log Message:
-----------
test-runner: allow source tree root for -k
Allow passing source tree root for -k option, look up kernel below it.
Commit: 908c14fc3abb96b553821aa81c88f4604af91379
https://github.com/bluez/bluez/commit/908c14fc3abb96b553821aa81c88f4604af91379
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M tools/test-runner.c
Log Message:
-----------
test-runner: use virtio-serial for implementing -u device forwarding
Using pci-serial to forward eg. btvirt sockets is unreliable, as qemu or
kernel seems to be sometimes dropping part of the sent data or insert
spurious \0 bytes, leading to sporadic errors like:
kernel: Bluetooth: hci0: command 0x0c52 tx timeout
kernel: Bluetooth: hci0: Opcode 0x0c52 failed: -110
btvirt: packet error, unknown type: 0
This appears to occur most often when host system is under load, e.g.
due to multiple test-runners running at the same time. The problem is
not specific to btvirt, but seems to be in the qemu serial device layer
vs. kernel interaction.
Change test-runner to use virtserialport to forward the btvirt
connection inside the VM, as virtio-serial doesn't appear to have these
problems.
Commit: 7856de4d69d66d360616ddfd071171358e831ea1
https://github.com/bluez/bluez/commit/7856de4d69d66d360616ddfd071171358e831ea1
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M doc/ci.config
M doc/test-runner.rst
M doc/tester.config
Log Message:
-----------
doc: enable CONFIG_VIRTIO_CONSOLE in tester config
Enable kernel option that allows using -device virtserialport in qemu.
This is easier to make work reliably than pci-serial channel.
Commit: 48cb22a572c7001bf4377cec761702857680f4c0
https://github.com/bluez/bluez/commit/48cb22a572c7001bf4377cec761702857680f4c0
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-14 (Thu, 14 May 2026)
Changed paths:
M doc/ci.config
M doc/test-runner.rst
M doc/tester.config
Log Message:
-----------
doc: enable KVM paravirtualization & clock support in tester kernel config
Enable KVM guest and PTP options in tester kernel config.
This allows synchronizing tester VM guest with host clock, needed for
testers that want to compare timestamps outside the VM guest.
Compare: https://github.com/bluez/bluez/compare/c4789506455f...48cb22a572c7
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ v5 00/16] Functional/integration testing
From: Luiz Augusto von Dentz @ 2026-05-14 19:11 UTC (permalink / raw)
To: patchwork-bot+bluetooth; +Cc: Pauli Virtanen, linux-bluetooth
In-Reply-To: <177878100755.31561.18184220318055008237.git-patchwork-notify@kernel.org>
Hi Pauli,
On Thu, May 14, 2026 at 1:51 PM <patchwork-bot+bluetooth@kernel.org> wrote:
>
> Hello:
>
> This series was applied to bluetooth/bluez.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>
> On Wed, 13 May 2026 19:17:17 +0300 you wrote:
> > Add framework for writing tests simulating "real" environments where
> > BlueZ and other parts of the stack run on different virtual machine
> > hosts that communicate with each other.
> >
> > *** v5 ***
> >
> > https://github.com/pv/bluez/compare/func-test-v4-r..func-test-v5
> >
> > [...]
>
> Here is the summary with links:
> - [BlueZ,v5,01/16] emulator: btvirt: check pkt lengths, don't get stuck on malformed
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e19c771841e9
> - [BlueZ,v5,02/16] emulator: btvirt: allow specifying where server unix sockets are made
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=5ee43f9993dd
> - [BlueZ,v5,03/16] emulator: btvirt: support SCO data packets
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=cc077e4a12dd
> - [BlueZ,v5,04/16] emulator: btdev: clear more state on Reset
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=f1a303e1d07a
> - [BlueZ,v5,05/16] test-runner: enable path argument for --unix
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=ff2ecb82e4c3
> - [BlueZ,v5,06/16] test-runner: Add -o/--option option
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=82c635c879bf
> - [BlueZ,v5,07/16] test-runner: allow source tree root for -k
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=1929b3a99d2f
> - [BlueZ,v5,08/16] test-runner: use virtio-serial for implementing -u device forwarding
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=908c14fc3abb
> - [BlueZ,v5,09/16] doc: enable CONFIG_VIRTIO_CONSOLE in tester config
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=7856de4d69d6
> - [BlueZ,v5,10/16] doc: enable KVM paravirtualization & clock support in tester kernel config
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=48cb22a572c7
Push the ones that didn't introduce new functionality, there were some
complaints from the likes of checkpatch regarding scripts with execute
permission, and Id like to go more in detail about how to write tests
and what is the RPC message protocol since we could in teory use the
same protocol used for autopts for example.
> - [BlueZ,v5,11/16] doc: add functional/integration testing documentation
> (no matching commit)
> - [BlueZ,v5,12/16] test: add functional/integration testing framework
> (no matching commit)
> - [BlueZ,v5,13/16] build: add functional testing target
> (no matching commit)
> - [BlueZ,v5,14/16] test: functional: impose Python code formatting
> (no matching commit)
> - [BlueZ,v5,15/16] test: functional: add some Agent1 interface tests
> (no matching commit)
> - [BlueZ,v5,16/16] test: functional: add basic obex file transfer tests
> (no matching commit)
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
>
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Bluetooth: HCI Create Connection issues default page-scan parameters (R2, clock_offset=0) instead of values from inquiry cache, causes Page Timeout on BR/EDR audio device
From: Luiz Augusto von Dentz @ 2026-05-14 19:33 UTC (permalink / raw)
To: Jacob Mills; +Cc: linux-bluetooth
In-Reply-To: <6890c968-f662-40db-a30d-775bc6593494@gmail.com>
Hi Jacob,
On Thu, May 14, 2026 at 3:10 PM Jacob Mills <jacobmills1997@gmail.com> wrote:
>
> Hi,
>
> Filing this for a 100%-reproducible BR/EDR pairing failure on a recent
> Fedora kernel against a 2015-era audio speaker, with btmon evidence
> pointing at the kernel's HCI Create Connection path ignoring
> inquiry-cache page parameters. The same physical hardware pairs the same
> speaker successfully on Windows.
>
>
> SUMMARY
> -------
>
> When pairing a BR/EDR-only audio device that advertises Page Scan
> Repetition Mode R1 with a non-zero clock offset, the kernel issues HCI
> Create Connection with default values (R2, clock_offset=0). The page
> never reaches the remote device and Connect Complete returns with status
> Page Timeout (0x04) after the default 5.12s page timeout. Pairing fails
> every time. The inquiry that immediately preceded the pair attempt was
> observed by the kernel (HCI Event #3 below) and contained the correct
> page parameters, so the data was available to the host stack -- it just
> was not used in the subsequent Create Connection.
>
>
> AFFECTED SYSTEM
> ---------------
>
> Distribution Fedora 44
> Kernel 7.0.6-200.fc44.x86_64
> linux-firmware 20260410-1.fc44
> BlueZ 5.86-4.fc44 (bluetoothd and bluetoothctl)
> Controller MediaTek MT7922 (BlueZ manufacturer id 0x001d / 29)
> USB ID 0489:e10d (Foxconn / Hon Hai), bcdDevice 0.01
> Combo card (BT + Wi-Fi on shared antennas; Wi-Fi was
> on 5 GHz at time of failure; also reproduces with
> Wi-Fi disabled)
> Controller MAC D8:B3:2F:44:DC:DE
> Remote device Edifier Luna Eclipse HD (e25HD) powered speaker
> (BR/EDR-only, A2DP Sink + AVRCP, manuf-id "Fihonest")
> Remote MAC 40:EF:4C:E0:B6:7B
>
> Three kernels are installed locally; a regression test on
> 6.19.10-300.fc44 has not yet been run. Happy to do that and follow up.
>
>
> REPRODUCIBILITY
> ---------------
>
> 100% reproducible on this kernel/firmware/hardware combination across:
>
> * bluetooth.service restart
> * modprobe -r btusb && modprobe btusb (full firmware reload, confirmed
> by matching "usbcore: deregistering/registered new interface driver
> btusb" pair in dmesg)
> * bluetoothctl power off/on (HCI Reset)
> * USB autosuspend disabled
> (echo on > /sys/bus/usb/devices/1-6/power/control)
> * Wi-Fi radio disabled (rules out MT7922 BT/WiFi antenna coex)
> * Fresh 60-second speaker power cycle
> * Fresh bond state on the laptop (no on-disk bond record)
>
> The Linux side discovers the speaker reliably via `scan bredr` at strong
> signal (-55 to -58 dBm). Only the page-following-pair fails.
>
>
> REPRODUCER
> ----------
>
> In a single bluetoothctl session, with the speaker freshly power-cycled
> and in BT input mode (solid blue LED), no other host bonded to the speaker:
>
> [bluetoothctl]# scan bredr
> ... [NEW] Device 40:EF:4C:E0:B6:7B EDIFIER Luna Eclipse HD
> ... [CHG] Device 40:EF:4C:E0:B6:7B RSSI: 0xffffffc8 (-56)
> [bluetoothctl]# scan off
> [bluetoothctl]# pair 40:EF:4C:E0:B6:7B
> Attempting to pair with 40:EF:4C:E0:B6:7B
> Failed to pair: org.bluez.Error.ConnectionAttemptFailed
>
> The same outcome occurs with `connect` (post-bond) -- both surface as
> the same HCI Page Timeout underneath.
>
>
> THE BUG, FROM BTMON
> -------------------
>
> The relevant excerpt (full snoop file attached):
>
> > HCI Event: Extended Inquiry Result (0x2f) plen 255 #3 35.314602
> Num responses: 1
> Address: 40:EF:4C:E0:B6:7B
> Page scan repetition mode: R1 (0x01) <-- speaker advertises R1
> Class: 0x240428 (Audio/Video, HiFi Audio Device)
> Clock offset: 0x3f03 <-- non-zero, valid
> RSSI: -58 dBm (0xc6)
> Name (complete): EDIFIER Luna Eclipse HD
> Service UUIDs: A2DP Sink/Source, AVRCP Target/Controller
>
> [ ~12s of `scan off`, MGMT Add Device, MGMT Pair Device ]
>
> < HCI Command: Create Connection (0x01|0x0005) plen 13 #11 47.576809
> Address: 40:EF:4C:E0:B6:7B
> Packet type: 0xcc18
> Page scan repetition mode: R2 (0x02) <-- kernel uses R2,
> ignoring cache R1
> Page scan mode: Mandatory (0x00)
> Clock offset: 0x0000 <-- kernel uses 0,
> ignoring cache 0x3f03
> Role switch: Allow peripheral (0x01)
>
> > HCI Event: Command Status (0x0f) plen 4 #12 47.577608
> Create Connection (0x01|0x0005) ncmd 1
> Status: Success (0x00)
>
> > HCI Event: Connect Complete (0x03) plen 11 #13 52.698868
> Status: Page Timeout (0x04)
> Address: 40:EF:4C:E0:B6:7B
> Link type: ACL (0x01)
> <-- 5.122s after
> Create Connection
> <-- = default Page Timeout
> (0x2000 slots)
>
> The kernel issued Create Connection 12 seconds after it observed the EIR
> for this address. The inquiry cache entry should still have been valid
> (default eviction is 60s). Either the cache is not being read on this
> code path, the inquiry result is not populating the cache, or the cached
> PageScanRepetitionMode / clock_offset fields are not being plumbed into
> hci_acl_create_connection() (or equivalent).
>
> For a device using R1 (1.28s page-scan-window cycle) the host-side hint
> should reflect that so the controller can size its page train timing
> appropriately; pairing with default R2 + null clock offset against an R1
> device with a non-zero clock offset means the page train is misaligned
> and the page misses entirely within the 5.12s window. On Windows, with
> the same physical controller, pairing succeeds -- so Windows clearly
> does plumb the inquiry-result page parameters into its page command.
>
>
> SURFACE-LEVEL ERRORS THIS PRODUCES
> ----------------------------------
>
> Depending on call site, BlueZ-userspace remaps the underlying HCI Page
> Timeout (status 0x04) to different D-Bus errors, which can mislead
> triage:
>
> bluetoothctl pair -> org.bluez.Error.ConnectionAttemptFailed
> bluetoothctl connect -> org.bluez.Error.Failed
> br-connection-page-timeout
> bluetoothd (audio path) -> avdtp_connect_cb() connect to
> 40:EF:4C:E0:B6:7B: Host is down (112)
>
> All three are the same HCI Page Timeout under the hood.
>
>
> WHAT WAS RULED OUT
> ------------------
>
> Speaker hardware OK -- pairs with other devices, pairs on
> Windows on the same physical host
> MT7922 controller hardware OK -- works on Windows; BR/EDR scan finds
> the speaker at -55 to -58 dBm
> Stale kernel / firmware No -- both current (linux-firmware
> 20260410, kernel 7.0.6)
> Bond conflict / stale key No -- empty /var/lib/bluetooth/.../<dev>
> Other host hogging link No -- confirmed no other paired/connected
> device
> USB autosuspend on btusb No -- power/control: on,
> runtime_status: active
> Wi-Fi/BT antenna coex No -- fails identically with `nmcli radio
> wifi off`
> Stale BlueZ device cache No -- persists after `bluetoothctl remove`,
> fresh discovery, full daemon restart
> Stale kernel HCI state No -- persists after modprobe -r/+ btusb
> Discovery transport (LE) Not it -- explicitly using `scan bredr`,
> speaker appears reliably
>
>
> RELATED CONTROLLER QUIRK IN DMESG (probably unrelated)
> ------------------------------------------------------
>
> Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
> advertised, but not supported.
>
> This is a known MT7922 firmware quirk for ESCO setup and would not
> affect BR/EDR ACL paging. Listing only in case it is relevant.
>
>
> ATTACHMENTS
> -----------
>
> bt.snoop -- full btmon capture covering the failing pair attempt
> (sudo btmon -w /tmp/bt.snoop, captured during
> `bluetoothctl scan bredr ; pair 40:EF:4C:E0:B6:7B`).
>
>
> OPEN QUESTION FOR MAINTAINERS
> -----------------------------
>
> Is hci_create_connection() (or whichever code path the kernel's
> mgmt_pair_device ends up calling) expected to look up the inquiry cache
> for the target BD_ADDR and pull PageScanRepetitionMode / clock_offset
> from there? Or is the userspace MGMT Pair Device (0x0019) opcode
> expected to carry these parameters?
>
> If the latter, this could equally be a BlueZ userspace bug not
> forwarding inquiry data into the mgmt call. The trace above shows the
> inquiry data reaching the kernel; whether it survives into the
> create-connection path is the open question.
>
> Have a great day,
> Jacob Mills
It took longer to read all this than to just check if we perform
inquiry caching:
https://github.com/bluez/bluetooth-next/blob/workflow/net/bluetooth/hci_sync.c#L6945
https://github.com/bluez/bluetooth-next/blob/workflow/include/net/bluetooth/hci_core.h#L905
This is old code that hasn't been touched for ages, before MGMT
interface was introduced, so I have no idea how it wouldn't use the
cached values, except perhaps if there is a reset that flushes the
cache or something similar.
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: [v2] Bluetooth: btintel_pcie: Fix incorrect MAC access programming
From: bluez.test.bot @ 2026-05-14 20:35 UTC (permalink / raw)
To: linux-bluetooth, kiran.k
In-Reply-To: <20260514190248.1275299-1-kiran.k@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1526 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=1094956
---Test result---
Test Summary:
CheckPatch PASS 0.75 seconds
GitLint FAIL 0.20 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 26.73 seconds
CheckAllWarning PASS 29.20 seconds
CheckSparse PASS 27.72 seconds
BuildKernel32 PASS 25.86 seconds
TestRunnerSetup PASS 570.97 seconds
IncrementalBuild PASS 25.27 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: btintel_pcie: Fix incorrect MAC access programming
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
19: B1 Line exceeds max length (87>80): "v1: https://lore.kernel.org/linux-bluetooth/20260511133932.1217624-1-kiran.k@intel.com/"
https://github.com/bluez/bluetooth-next/pull/192
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: btnxpuart: Fix use-after-free in probe error path
From: Zhao Dongdong @ 2026-05-15 0:46 UTC (permalink / raw)
To: amitkumar.karwar, neeraj.sanjaykale, marcel
Cc: linux-bluetooth, Zhao Dongdong
From: Zhao Dongdong <zhaodongdong@kylinos.cn>
In nxp_serdev_probe(), if hci_register_dev() succeeds but ps_setup()
fails, the error path jumps to 'probe_fail' which only calls
hci_free_dev() and asserts the reset GPIO, but does NOT call
hci_unregister_dev() first.
This leaves the HCI device registered in the system with its backing
memory freed, leading to a use-after-free when userspace subsequently
accesses the device (e.g. via hciconfig or bluetoothd).
Fix by adding a 'probe_fail_unregister' label that calls
hci_unregister_dev() before falling through to the existing
'probe_fail' label. The original 'probe_fail' label is preserved
for the case where hci_register_dev() itself fails (device was
never registered, so no unregister is needed).
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
---
v3: fix gitlint WARNING
v2: fix SubjectPrefix
---
drivers/bluetooth/btnxpuart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index e7036a48ce48..a4d7747e5be0 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -1907,13 +1907,15 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
}
if (ps_setup(hdev))
- goto probe_fail;
+ goto probe_fail_unregister;
hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
nxp_coredump_notify);
return 0;
+probe_fail_unregister:
+ hci_unregister_dev(hdev);
probe_fail:
reset_control_assert(nxpdev->pdn);
hci_free_dev(hdev);
--
2.25.1
^ permalink raw reply related
* RE: [v3] Bluetooth: btnxpuart: Fix use-after-free in probe error path
From: bluez.test.bot @ 2026-05-15 1:53 UTC (permalink / raw)
To: linux-bluetooth, winter91
In-Reply-To: <tencent_F2E2AF1B6F510577B10C6897ED768BBBAF07@qq.com>
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1095065
---Test result---
Test Summary:
CheckPatch PASS 0.63 seconds
GitLint PASS 0.21 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 27.86 seconds
CheckAllWarning PASS 30.47 seconds
CheckSparse PASS 28.77 seconds
BuildKernel32 PASS 26.72 seconds
TestRunnerSetup PASS 586.50 seconds
IncrementalBuild PASS 25.96 seconds
https://github.com/bluez/bluetooth-next/pull/193
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: Shuai Zhang @ 2026-05-15 2:41 UTC (permalink / raw)
To: makro-kernel
Cc: luiz.dentz@gmail.com, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
In-Reply-To: <GCBTvsv1x8qAB3ZmSCpTLo7M63lTTXM2c5n1TJLmQuus0g4gViSSJVRZzl6CzehnMdSHDqtZkQA33RYCVSxdAm7tGEeVYCflhV3QgbLIcfg=@proton.me>
Hi Makro,
Thanks for the detailed analysis.
On 5/14/2026 10:44 AM, makro-kernel wrote:
> Hi Shuai, Luiz,
>
> I sent a patch earlier today touching the same function for a related
> but distinct failure mode in the same family of chips, and only just
> saw this thread.
>
> https://lore.kernel.org/linux-bluetooth/aD_Lix2EVXOHmbZ4L1CunlWiLqfiKlU_1_FcVh4CBuIgud4kmE_544xjW2zFKsmh4pNAo9yIQ7q8_GZ4YcmgAXPp8LgW9rfWKqnu06WSjgk=@proton.me/T/#u
>
> In my case the *outer* check fails first: on Foxconn USB 0489:e10a
> (Qualcomm WCN6855/WCN785x, ROM 0x00190200) the chip reports
> QCA_CHECK_STATUS = 0xe0 (PATCH_UPDATED | SYSCFG_UPDATED) on every
> probe, so btusb_setup_qca() never reaches load_rampatch() or
> load_nvm(), returns 0, and the controller runs unpatched firmware.
>
> AVDTP setup later fails on Acquire and A2DP audio cannot stream. The
> PATCH_UPDATED bit appears to persist across cold boots somewhere on
> chip -- originally set by Windows on dual-boot-then-Linux systems
> we've seen, but the bit sticks even after a successful Linux firmware
> upload, so subsequent boots also see 0xe0 and skip.
>
> The rampatch itself also persists on this silicon at least across
> suspend/hibernate resume cycles and driver reload (whether it
> survives a true cold boot I haven't isolated). Either way, once an
> upload has succeeded the chip reports patch_version equal to the
> file's version on subsequent probes, which is exactly the condition
> your patch addresses. With my outer bypass in place but without your
> inner change, the second and subsequent probes hit the existing
> `rver_patch <= ver_patch` check, return -EINVAL, and controller
> setup aborts entirely:
>
> Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00190200.bin
> Bluetooth: hci0: QCA: patch rome 0x190200 build 0x8567, firmware rome 0x190200 build 0x8567
> Bluetooth: hci0: rampatch file version did not match with firmware
> (btusb_setup_qca returns -EINVAL, hci0 never finishes registering)
>
> So your fix is doing the right thing here, and on this hardware both
> sides are needed together for the chip to come up cleanly across
> reload / reboot cycles.
>
> In my local tree I skip reuploading on equal versions rather than
> re-uploading on every probe:
>
> if (rver_rom != ver_rom) {
> bt_dev_err(hdev, "rampatch file ROM did not match controller");
> err = -EINVAL;
> goto done;
> }
>
> if (rver_patch <= ver_patch) {
> bt_dev_info(hdev, "QCA: rampatch already current, skipping download");
> err = 0;
> goto done;
> }
>
> err = btusb_setup_qca_download_fw(hdev, fw, info->rampatch_hdr);
I tested on another device with the same ROM version (0x00190200) but
a different USB ID (0cf3:e700). After a cold reboot the chip reports
firmware build 0x43fb (ROM state), meaning firmware is reset on power
cycle and QCA_CHECK_STATUS does not return 0xe0. The rampatch download
proceeds normally every boot without any bypass.
This suggests the NVM-persistent status bit behavior you described is
specific to certain vendor configurations (e.g. Foxconn 0489:e10a)
rather than a property of the ROM version itself.
Given that, I wonder if removing the QCA_CHECK_STATUS guard
unconditionally for all QCA USB chips is the right approach. For chips
that reset firmware on cold boot, the unconditional re-upload adds
unnecessary overhead on every probe. A device-specific quirk flag
(keyed on USB ID) might be a more targeted fix, leaving the existing
optimization intact for chips that don't exhibit the NVM persistence
issue.
My inner patch (changing <= to <) addresses the USB disconnect
recovery case and is independent of the chip's NVM behavior, so it
should apply broadly regardless of how the outer check is handled.
Please correct me if I have misunderstood anything.
Hi Luiz, could you take a look at my patch when you get a chance?
https://lore.kernel.org/linux-bluetooth/8f5362ca-5513-4d9a-8922-6603783c9ae7@oss.qualcomm.com
>
> Best,
> Makro
Thanks,
Shuai
^ permalink raw reply
* Re: Linux 7.1-rc3 regression (Bluetooth)
From: August Wikerfors @ 2026-05-15 2:26 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: linux-kernel, linux-bluetooth, Linux kernel regressions list,
stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov,
markus.suvanto
In-Reply-To: <01ffb0cc-dcf6-4e60-adf3-fbb96e0666d0@leemhuis.info>
On 2026-05-11 08:30, Thorsten Leemhuis wrote:
> On 5/11/26 07:17, markus.suvanto@gmail.com wrote:
>> Hello
>>
>> I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start
>> hci0: Failed to send wmt func ctrl (-22)
>> My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206
>
> Thx for your report. FWIW, there are two proposed fixed for this change
> floating around:
>
> https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
>
> Given that this is the third revert within a short time-frame I wonder
> if we should fast-track a fix (once ready) to spare more users the pain
> of bisecting & reporting.
FYI the commit that caused this regression was backported to the latest
stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after
updating to 7.0.7 and can confirm that the patch from the second link
fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20
("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull
request [1] has been made to the net tree. Unfortunately this seems to
have been a few hours too late to make it into the net pull request for
7.1-rc4 [2], so the fix might not get into mainline until next week.
As a side note, it is unfortunate that there does not seem to be a
process to prevent patches that are known to cause regressions from
being backported to stable releases. As far as I can tell, this was
added to regzbot tracking [3] a day before the culprit was queued for
stable [4], so such a process could have prevented this regression in
stable releases.
[1] https://lore.kernel.org/all/20260514172340.1515042-1-luiz.dentz@gmail.com/
[2] https://lore.kernel.org/all/20260514142703.267609-1-pabeni@redhat.com/
[3] https://lore.kernel.org/all/8a17737e-ba9b-4842-a429-c4eab3abcdec@leemhuis.info/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=7780f283d14c8c6bf40fe9262219ad821a5dae80
Regards,
August Wikerfors
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: makro-kernel @ 2026-05-15 3:05 UTC (permalink / raw)
To: Shuai Zhang
Cc: luiz.dentz@gmail.com, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
In-Reply-To: <51a08590-a662-45b2-ba04-195b020c26cd@oss.qualcomm.com>
Hi Shuai,
Thanks for testing. I agree, then the unconditional bypass in my patch
is too broad and a quirk-flag approach is better. I'll wait for your
patch to land and rebase on top.
Thanks,
Makro
^ permalink raw reply
* [REGRESSION] MT7925 Bluetooth fails to initialize after btmtk fix 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length")
From: Aaron Muir Hamilton @ 2026-05-15 2:49 UTC (permalink / raw)
To: linux-bluetooth
Cc: regressions, Marcel Holtmann, Tristan Madani,
Luiz Augusto von Dentz, Greg Kroah-Hartman
I bisected a regression on MediaTek MT7925 (Framework Desktop) in linux-7.0.y which appears responsible for this issue. It initializes and works correctly in 7.0.6 but not in 7.0.7.
The bisect landed on commit 70d37a8b9229e394cc17ddad47e90b81d80fcd09 which is a backport of 634a4408c0615c523cf7531790f4f14a422b9206:
commit 634a4408c0615c523cf7531790f4f14a422b9206
Author: Tristan Madani <tristan@talencesecurity.com>
Date: Tue Apr 21 11:14:54 2026 +0000
Bluetooth: btmtk: validate WMT event SKB length before struct access
btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to
struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc
(9 bytes) without first checking that the SKB contains enough data.
A short firmware response causes out-of-bounds reads from SKB tailroom.
Use skb_pull_data() to validate and advance past the base WMT event
header. For the FUNC_CTRL case, pull the additional status field bytes
before accessing them.
Fixes: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In dmesg, the failure shows up as:
Bluetooth: hci0: Failed to send wmt func ctrl (-22)
Cheers!
#regzbot introduced: 634a4408c0615c523cf7531790f4f14a422b9206
--
Aaron Muir Hamilton
+1 313 240 2152 +1 307 365 7527
^ permalink raw reply
* Re: Linux 7.1-rc3 regression (Bluetooth)
From: Greg KH @ 2026-05-15 5:37 UTC (permalink / raw)
To: August Wikerfors
Cc: Thorsten Leemhuis, linux-kernel, linux-bluetooth,
Linux kernel regressions list, stable, Luiz Augusto von Dentz,
Pauli Virtanen, Mikhail Gavrilov, markus.suvanto
In-Reply-To: <51b55b97-615b-4f5e-b454-df646f4058b7@augustwikerfors.se>
On Fri, May 15, 2026 at 04:26:38AM +0200, August Wikerfors wrote:
> On 2026-05-11 08:30, Thorsten Leemhuis wrote:
> > On 5/11/26 07:17, markus.suvanto@gmail.com wrote:
> > > Hello
> > >
> > > I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth didn't start
> > > hci0: Failed to send wmt func ctrl (-22)
> > > My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206
> >
> > Thx for your report. FWIW, there are two proposed fixed for this change
> > floating around:
> >
> > https://lore.kernel.org/all/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> > https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
> >
> > Given that this is the third revert within a short time-frame I wonder
> > if we should fast-track a fix (once ready) to spare more users the pain
> > of bisecting & reporting.
>
> FYI the commit that caused this regression was backported to the latest
> stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after
> updating to 7.0.7 and can confirm that the patch from the second link
> fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20
> ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull
> request [1] has been made to the net tree. Unfortunately this seems to
> have been a few hours too late to make it into the net pull request for
> 7.1-rc4 [2], so the fix might not get into mainline until next week.
>
> As a side note, it is unfortunate that there does not seem to be a
> process to prevent patches that are known to cause regressions from
> being backported to stable releases. As far as I can tell, this was
> added to regzbot tracking [3] a day before the culprit was queued for
> stable [4], so such a process could have prevented this regression in
> stable releases.
You can email stable@vger to let us know to drop a patch, or when the
-rcs are released, respond to the offending patch in that list. THat's
why we have -rc releases!
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: hci_uart: fix UAF in hci_uart_tty_close()
From: Greg KH @ 2026-05-15 6:10 UTC (permalink / raw)
To: w15303746062
Cc: pmenzel, marcel, luiz.dentz, linux-bluetooth, linux-serial,
linux-kernel, Mingyu Wang
In-Reply-To: <20260514151722.382161-1-w15303746062@163.com>
On Thu, May 14, 2026 at 11:17:22PM +0800, w15303746062@163.com wrote:
> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
> A Use-After-Free (UAF) vulnerability and a subsequent kernel panic were
> observed in hci_uart_write_work() due to a race condition between the
> initialization of the HCI UART line discipline and concurrent TTY hangup.
>
> This issue was triggered by our custom device emulation and fuzzing
> framework (DevGen) on the v6.18 kernel. Due to the highly timing-dependent
> nature of this race condition (requiring a precise interleaving of
> TIOCVHANGUP and protocol setup), Syzkaller failed to extract a reliable
> standalone C reproducer (reproducer is too unreliable: 0.00).
>
> The crash trace is as follows:
> ODEBUG: free active (active state 0) object: ffff88804024e870 object type: work_struct hint: hci_uart_write_work+0x0/0x940
> WARNING: CPU: 0 PID: 338273 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0
> ...
> Call Trace:
> <TASK>
> debug_check_no_obj_freed+0x3ec/0x520
> kfree+0x3f0/0x6c0
> hci_uart_tty_close+0x127/0x2a0
> tty_ldisc_close+0x113/0x1a0
> tty_ldisc_kill+0x8e/0x150
> tty_ldisc_hangup+0x3c1/0x730
> __tty_hangup.part.0+0x3fd/0x8a0
> tty_ioctl+0x120f/0x1690
> __x64_sys_ioctl+0x18f/0x210
> do_syscall_64+0xcb/0xfa0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> </TASK>
>
> The issue arises because the workqueues (init_ready and write_work) are
> only cancelled if the HCI_UART_PROTO_READY flag is set. However, during
> the protocol initialization phase (HCI_UART_PROTO_INIT), the underlying
> protocol may schedule work. If a hangup occurs before the setup completes
> and the READY flag is set, hci_uart_tty_close() skips the cancel_work_sync()
> calls and proceeds to free the `hu` struct. When the delayed workqueue
> executes, it blindly dereferences the freed `hu` struct.
>
> Fix this by moving the cancel_work_sync() calls outside the
> HCI_UART_PROTO_READY check, ensuring that any pending works are
> unconditionally cancelled before the hci_uart structure is freed.
> Note that hu->init_ready and hu->write_work are initialized in
> hci_uart_tty_open(), so it is always safe to call cancel_work_sync()
> on them in hci_uart_tty_close(), even if the protocol was never
> fully attached.
>
> Fixes: 3b799254cf6f ("Bluetooth: hci_uart: Cancel init work before unregistering")
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> ---
> Changes in v2:
> - Added KASAN/ODEBUG crash trace.
> - Added explanation for the absence of a standalone reproducer (highly timing-dependent race condition).
> - Added Fixes tag pointing to commit 3b799254cf6f.
>
> drivers/bluetooth/hci_ldisc.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index 275ea865bc29..566e1c525ee2 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -544,14 +544,18 @@ static void hci_uart_tty_close(struct tty_struct *tty)
> if (hdev)
> hci_uart_close(hdev);
>
> + /*
> + * Always cancel workqueues unconditionally before freeing the hu
> + * struct, as they might be active during the PROTO_INIT phase.
> + */
> + cancel_work_sync(&hu->init_ready);
> + cancel_work_sync(&hu->write_work);
> +
> if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
> percpu_down_write(&hu->proto_lock);
> clear_bit(HCI_UART_PROTO_READY, &hu->flags);
> percpu_up_write(&hu->proto_lock);
>
> - cancel_work_sync(&hu->init_ready);
> - cancel_work_sync(&hu->write_work);
> -
> if (hdev) {
> if (test_bit(HCI_UART_REGISTERED, &hu->flags))
> hci_unregister_dev(hdev);
> --
> 2.34.1
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH net] Bluetooth: ISO: drop ISO_END frames received without prior ISO_START
From: David Carlier @ 2026-05-15 6:25 UTC (permalink / raw)
To: netdev
Cc: linux-bluetooth, David Carlier, stable, Marcel Holtmann,
Luiz Augusto von Dentz, linux-kernel
ISO data PDUs carry a packet-boundary flag indicating START, CONT, END
or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing
ISO_START by checking conn->rx_len before touching conn->rx_skb, but
ISO_END does not.
If a peer sends an ISO_END as the first packet on a fresh ISO
connection, conn->rx_skb is still NULL and conn->rx_len is zero, so
skb_put(conn->rx_skb, ...) dereferences NULL and oopses. For BIS,
where receivers sync to a broadcaster without pairing, any broadcaster
on the air can trigger this.
Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment
is logged and dropped instead of crashing the host.
Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: David Carlier <devnexen@gmail.com>
---
net/bluetooth/iso.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index 7cb2864fe872..b971281f0a2b 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -2593,6 +2593,11 @@ int iso_recv(struct hci_dev *hdev, u16 handle, struct sk_buff *skb, u16 flags)
break;
case ISO_END:
+ if (!conn->rx_len) {
+ BT_ERR("Unexpected end frame (len %d)", skb->len);
+ goto drop;
+ }
+
skb_copy_from_linear_data(skb, skb_put(conn->rx_skb, skb->len),
skb->len);
conn->rx_len -= skb->len;
--
2.53.0
^ permalink raw reply related
* [PATCH v3] Bluetooth: hci_uart: fix UAF in hci_uart_tty_close()
From: w15303746062 @ 2026-05-15 6:50 UTC (permalink / raw)
To: pmenzel, marcel, luiz.dentz, linux-bluetooth
Cc: linux-serial, linux-kernel, greg, stable, Mingyu Wang
In-Reply-To: <505b56bd-e5fd-4feb-a6e3-1d8269609277@molgen.mpg.de>
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
A Use-After-Free (UAF) vulnerability and a subsequent kernel panic were
observed in hci_uart_write_work() due to a race condition between the
initialization of the HCI UART line discipline and concurrent TTY hangup.
This issue was triggered by our custom device emulation and fuzzing
framework (DevGen) on the v6.18 kernel. Due to the highly timing-dependent
nature of this race condition (requiring a precise interleaving of
TIOCVHANGUP and protocol setup), Syzkaller failed to extract a reliable
standalone C reproducer (reproducer is too unreliable: 0.00).
The crash trace is as follows:
ODEBUG: free active (active state 0) object: ffff88804024e870 object type: work_struct hint: hci_uart_write_work+0x0/0x940
WARNING: CPU: 0 PID: 338273 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0
...
Call Trace:
<TASK>
debug_check_no_obj_freed+0x3ec/0x520
kfree+0x3f0/0x6c0
hci_uart_tty_close+0x127/0x2a0
tty_ldisc_close+0x113/0x1a0
tty_ldisc_kill+0x8e/0x150
tty_ldisc_hangup+0x3c1/0x730
__tty_hangup.part.0+0x3fd/0x8a0
tty_ioctl+0x120f/0x1690
__x64_sys_ioctl+0x18f/0x210
do_syscall_64+0xcb/0xfa0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The issue arises because the workqueues (init_ready and write_work) are
only cancelled if the HCI_UART_PROTO_READY flag is set. However, during
the protocol initialization phase (HCI_UART_PROTO_INIT), the underlying
protocol may schedule work. If a hangup occurs before the setup completes
and the READY flag is set, hci_uart_tty_close() skips the cancel_work_sync()
calls and proceeds to free the `hu` struct. When the delayed workqueue
executes, it blindly dereferences the freed `hu` struct.
Fix this by moving the cancel_work_sync() calls outside the
HCI_UART_PROTO_READY check, ensuring that any pending works are
unconditionally cancelled before the hci_uart structure is freed.
Note that hu->init_ready and hu->write_work are initialized in
hci_uart_tty_open(), so it is always safe to call cancel_work_sync()
on them in hci_uart_tty_close(), even if the protocol was never
fully attached.
Fixes: 3b799254cf6f ("Bluetooth: hci_uart: Cancel init work before unregistering")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
Changes in v3:
- Added 'Cc: stable' tag as requested by the stable bot.
Changes in v2:
- Added KASAN/ODEBUG crash trace.
drivers/bluetooth/hci_ldisc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 275ea865bc29..566e1c525ee2 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -544,14 +544,18 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
+ /*
+ * Always cancel workqueues unconditionally before freeing the hu
+ * struct, as they might be active during the PROTO_INIT phase.
+ */
+ cancel_work_sync(&hu->init_ready);
+ cancel_work_sync(&hu->write_work);
+
if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
percpu_down_write(&hu->proto_lock);
clear_bit(HCI_UART_PROTO_READY, &hu->flags);
percpu_up_write(&hu->proto_lock);
- cancel_work_sync(&hu->init_ready);
- cancel_work_sync(&hu->write_work);
-
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, &hu->flags))
hci_unregister_dev(hdev);
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox