* [Bug 221524] Intel 8265 Bluetooth regression (BLE hearing aid unusable) in kernel 6.12 vs 6.1
From: bugzilla-daemon @ 2026-05-15 12:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221524-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221524
Darek (t.darcin10@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Intel 8265 Bluetooth |Intel 8265 Bluetooth
|(8087:0a2b) BLE |regression (BLE hearing aid
|connectivity regression |unusable) in kernel 6.12 vs
|observed after kernel |6.1
|upgrade. |
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221524] New: Intel 8265 Bluetooth (8087:0a2b) BLE connectivity regression observed after kernel upgrade.
From: bugzilla-daemon @ 2026-05-15 12:12 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221524
Bug ID: 221524
Summary: Intel 8265 Bluetooth (8087:0a2b) BLE connectivity
regression observed after kernel upgrade.
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: t.darcin10@gmail.com
Regression: No
Regression report:
Intel 8265 Bluetooth (8087:0a2b) BLE connectivity regression observed after
kernel upgrade.
Environment:
- Debian 13 (trixie)
- Kernel: 6.12.86+deb13-amd64
- Previous working kernel: 6.1 (Debian 12)
- Bluetooth driver: btusb
- Device: Intel Dual Band Wireless-AC 8265
Problem:
BLE hearing aid device becomes unusable at normal distance (~0.5–1m).
Device only works when placed directly on top of the computer.
Classic Bluetooth devices (mouse, keyboard, phone audio) work normally.
This indicates BLE-specific regression rather than general Bluetooth failure.
Kernel logs:
----------------
iwlwifi 0000:3a:00.0: missed beacons exceeds threshold, but receiving data
Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not
supported
----------------
Observations:
- Wi-Fi and Bluetooth share Intel 8265 module
- Wi-Fi shows occasional missed beacon warnings
- Bluetooth firmware loads correctly
- No general HCI failure or device reset observed
- Issue is reproducible and consistent
Expected behavior:
BLE devices (hearing aid) should operate normally as in kernel 6.1.
Actual behavior:
Severe BLE range degradation only affecting hearing aid device.
Reproducibility:
100%
Regression:
Yes (worked on kernel 6.1, broken on 6.12)
Likely affected area:
btusb / Intel Bluetooth LE / PHY handling in kernel 6.12
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [syzbot] [bluetooth?] WARNING in hci_conn_drop (4)
From: syzbot @ 2026-05-15 12:05 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 5cbb61bf4168 arm64/fpsimd: ptrace: zero target's fpsimd_st..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=13f0ebce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a834c6344141a58b
dashboard link: https://syzkaller.appspot.com/bug?extid=195b4c12c5b8c9a8eb8b
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/04156ec16593/disk-5cbb61bf.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6bfa041e2c79/vmlinux-5cbb61bf.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a92d82d8a79e/Image-5cbb61bf.gz.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+195b4c12c5b8c9a8eb8b@syzkaller.appspotmail.com
------------[ cut here ]------------
workqueue: cannot queue hci_conn_timeout on wq hci4
WARNING: kernel/workqueue.c:2298 at __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296, CPU#0: kworker/0:5/4769
Modules linked in:
CPU: 0 UID: 0 PID: 4769 Comm: kworker/0:5 Tainted: G L syzkaller #0 PREEMPT
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: events l2cap_chan_timeout
pstate: 634000c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296
lr : __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296
sp : ffff800092887810
x29: ffff800092887850 x28: ffff700012510f78 x27: ffff0000d64aba88
x26: ffff0000d629f800 x25: 0000000000000008 x24: ffff0000d629f9c0
x23: dfff800000000000 x22: ffff0000de09572c x21: 0000000004208060
x20: ffff800089f06000 x19: ffff0000c5968a58 x18: 1fffe00035c20e20
x17: ffff8000888db000 x16: ffff80008898cfc0 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 2aca8fde2d60a500
x8 : 2aca8fde2d60a500 x7 : ffff8000804886d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff8000802f13b0
x2 : 0000000100000000 x1 : ffff0000de095700 x0 : 0000000000000000
Call trace:
__queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296 (P)
__queue_delayed_work+0xf4/0x2b4 kernel/workqueue.c:2548
queue_delayed_work_on+0xcc/0x140 kernel/workqueue.c:2600
queue_delayed_work include/linux/workqueue.h:711 [inline]
hci_conn_drop+0x174/0x29c include/net/bluetooth/hci_core.h:1712
l2cap_chan_del+0x220/0x48c net/bluetooth/l2cap_core.c:672
l2cap_chan_close+0x3e4/0x5ac net/bluetooth/l2cap_core.c:-1
l2cap_chan_timeout+0x120/0x29c net/bluetooth/l2cap_core.c:431
process_one_work+0x78c/0x173c kernel/workqueue.c:3302
process_scheduled_works+0xdc/0x13c kernel/workqueue.c:3385
worker_thread+0x770/0xbd0 kernel/workqueue.c:3466
kthread+0x2f0/0x3c0 kernel/kthread.c:436
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:842
irq event stamp: 81246
hardirqs last enabled at (81245): [<ffff800080351f60>] __cancel_work+0xf4/0x1a4 kernel/workqueue.c:4454
hardirqs last disabled at (81246): [<ffff80008034e144>] queue_delayed_work_on+0x54/0x140 kernel/workqueue.c:2596
softirqs last enabled at (81238): [<ffff800084aa1108>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
softirqs last enabled at (81238): [<ffff800084aa1108>] release_sock+0x150/0x228 net/core/sock.c:3825
softirqs last disabled at (81234): [<ffff800084aa0fec>] spin_lock_bh include/linux/spinlock.h:348 [inline]
softirqs last disabled at (81234): [<ffff800084aa0fec>] release_sock+0x34/0x228 net/core/sock.c:3812
---[ end trace 0000000000000000 ]---
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco-arduino-monza: Add Bluetooth UART node
From: Konrad Dybcio @ 2026-05-15 10:56 UTC (permalink / raw)
To: Shuai Zhang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, linux-bluetooth,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
In-Reply-To: <20260429103537.1282497-1-shuai.zhang@oss.qualcomm.com>
On 4/29/26 12:35 PM, Shuai Zhang wrote:
> The QCA2066 Bluetooth chip is powered by a board-level 3.3 V supply
> provided by the hardware. This change connects the Bluetooth
> controller via UART10, and the corresponding GPIO is used to enable
> the Bluetooth chip.
>
> basic function test step:
> - bluetoothctl power on/off
> - bluetoothctl scan bredr/le
> - bluetoothctl pair <remote device address>
> - bluetoothctl connect <remote device address>
>
> low-state test and state:
> - rtcwake -d /dev/rtc0 -m no -s 30 && systemctl suspend
>
> cat /sys/kernel/debug/suspend_stats
> success: 1
> fail: 0
> failed_freeze: 0
> failed_prepare: 0
> failed_suspend: 0
> failed_suspend_late: 0
> failed_suspend_noirq: 0
> failed_resume: 0
> failed_resume_early: 0
> failed_resume_noirq: 0
> failures:
> last_failed_dev:
>
> last_failed_errno: 0
> 0
> last_failed_step:
>
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
From: Konrad Dybcio @ 2026-05-15 10:52 UTC (permalink / raw)
To: Luca Weiss, Dmitry Baryshkov, Jeff Johnson, Baochen Qiang
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Koskovich, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Johannes Berg, Jeff Johnson,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <DI9X9D3TTIRE.1CGHQI2LEZ1UL@fairphone.com>
On 5/4/26 3:21 PM, Luca Weiss wrote:
> On Mon May 4, 2026 at 3:10 PM CEST, Konrad Dybcio wrote:
>> On 5/1/26 11:20 AM, Luca Weiss wrote:
>>> Hi Konrad,
>>>
>>> On Tue Apr 7, 2026 at 3:16 PM CEST, Konrad Dybcio wrote:
>>>> On 4/3/26 9:35 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, Apr 03, 2026 at 03:52:53PM +0200, Luca Weiss wrote:
>>>>>> Configure and enable the WiFi node, and add the required pinctrl to
>>>>>> provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.
>>>>>>
>>>>>> Thanks to Alexander Koskovich for helping with the bringup, adding
>>>>>> the missing pinctrl to make the WPSS stop crashing.
>>>>>>
>>>>>> Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY@fairphone.com/
>>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
>>>>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>>> index db72418b7195..d8ac495ca7c8 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>>> @@ -242,7 +242,7 @@ wcn6750-pmu {
>>>>>>
>>>>>> clocks = <&rpmhcc RPMH_RF_CLK1>;
>>>>>>
>>>>>> - pinctrl-0 = <&bluetooth_enable_default>;
>>>>>> + pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
>>>>>> pinctrl-names = "default";
>>>>>>
>>>>>> regulators {
>>>>>> @@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
>>>>>> qcom,tune-usb2-preem = /bits/ 8 <0x6>;
>>>>>> };
>>>>>>
>>>>>> +&pmk8550_gpios {
>>>>>> + pmk8550_sleep_clk_default: sleep-clk-default-state {
>>>>>> + pins = "gpio5";
>>>>>> + function = "func1";
>>>>>> + input-disable;
>>>>>> + output-enable;
>>>>>
>>>>> Hmm, if it's a sleep_clk, should it not be handled via the power
>>>>> sequencer?
>>>>
>>>> If you mean that it may be needed to toggle it with specific timings,
>>>> possibly.. seems that WCN6855 has a "xo-clk" GPIO defined. I requested
>>>> access to some docs that I think should have the answer, hopefully should
>>>> get it soon.
>>>
>>> Did you manage to get anything there yet?
>>
>> Yeah, sorry, it got lost in the sea of emails..
>>
>> The PDF talks about the electrical requirements of the clock signal and
>> the section titled "Power-up sequence timing" doesn't mention it at all,
>> so my assumption would be "OK so long as it's ticking before you power
>> up the WCN"
>
> Thanks for checking!
>
> Is this an R-b then?
Yes
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Bluetooth: L2CAP: missing length check before __unpack_control() in l2cap_data_rcv()
From: Alexandru Hossu @ 2026-05-15 10:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.dentz
Hi,
I found an out-of-bounds read in l2cap_data_rcv() in net/bluetooth/l2cap_core.c.
__unpack_control() at line 1070 is called without verifying the skb contains
enough bytes. The function reads 2 bytes (enhanced control) or 4 bytes
(extended control) from skb->data unconditionally:
__unpack_enhanced_control(get_unaligned_le16(skb->data), ...);
__unpack_extended_control(get_unaligned_le32(skb->data), ...);
The check at l2cap_recv_frame() line 6935 does not protect this. That check
is: if (len != skb->len). When the attacker sends a 0-byte PDU body with
header len=0, after skb_pull(L2CAP_HDR_SIZE) both len and skb->len are 0.
The comparison 0 != 0 is false so the frame is not dropped.
The result is a 2 or 4 byte read past the end of the skb data region.
After the call, skb_pull() for the control field size on the 0-byte skb
returns NULL (len > skb->len soft check at skb_pull_inline:2851), leaving
skb->len at 0 and the subsequent len = skb->len read also 0.
Trigger: send a 0-byte data PDU on an established ERTM or STREAMING channel.
Classic BT, adjacent radio range. Unauthenticated ACL connection is enough.
Suggested fix at the top of l2cap_data_rcv():
u16 ctrl_size = test_bit(FLAG_EXT_CTRL, &chan->flags) ?
L2CAP_EXT_CTRL_SIZE : L2CAP_ENH_CTRL_SIZE;
if (skb->len < ctrl_size) {
kfree_skb(skb);
return -EINVAL;
}
Tested on linux-next commit e98d21c170b0 (2026-05-08).
Alexandru
^ permalink raw reply
* Bluetooth: ISO: null ptr deref in iso_recv() on ISO_END without prior ISO_START
From: Alexandru Hossu @ 2026-05-15 10:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.dentz
Hi,
I found a null pointer dereference in iso_recv() in net/bluetooth/iso.c.
At line 2595-2596:
case ISO_END:
skb_copy_from_linear_data(skb,
skb_put(conn->rx_skb, skb->len), skb->len);
conn->rx_skb is passed to skb_put() without a NULL check.
It can be NULL in two cases. First, if ISO_END arrives without a prior
ISO_START frame, conn->rx_skb was never allocated. Second, the ISO_CONT
overflow error path at line 2581-2587 calls kfree_skb(conn->rx_skb) and
sets it to NULL. A subsequent ISO_END hits the same path.
The ISO_CONT case at line 2575 has a guard:
if (!conn->rx_len) {
goto drop;
}
ISO_END has no equivalent protection.
Suggested fix:
case ISO_END:
if (!conn->rx_skb)
goto drop;
skb_copy_from_linear_data(skb,
skb_put(conn->rx_skb, skb->len), skb->len);
Attack surface: CIS requires an established ACL connection. BIS requires
the victim to sync to a malicious broadcaster. Not zero-click but reachable
from an adjacent unauthenticated source on CIS paths.
Tested on linux-next commit e98d21c170b0 (2026-05-08).
Alexandru
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 10:20 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Bisected commit-id|634a4408c061 |634a4408c0615c523cf7531790f
| |4f14a422b9206
Status|NEW |RESOLVED
URL| |https://lore.kernel.org/all
| |/5i35wmc4z7sz54jo5uj6ywext2
| |enh4ik3oxmfmperqk2v5kc27@pp
| |vm6oodzipn/
Resolution|--- |CODE_FIX
--- Comment #5 from Artem S. Tashkinov (aros@gmx.com) ---
This commit should fix it:
https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
Not yet pushed to stable but hopefully will be there in time for 7.0.8.
Keep an eye on
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-7.0
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 10:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |erpumper@gmail.com
--- Comment #4 from Artem S. Tashkinov (aros@gmx.com) ---
*** Bug 221511 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221511] MT7925 7.1 rc does not work, but it works in kernel 7.0
From: bugzilla-daemon @ 2026-05-15 10:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221511-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221511
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #4 from Artem S. Tashkinov (aros@gmx.com) ---
*** This bug has been marked as a duplicate of bug 221521 ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 220922] btusb: Add USB ID 0x13d3:0x3625 for MediaTek MT7922
From: bugzilla-daemon @ 2026-05-15 9:42 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-220922-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=220922
--- Comment #4 from sunil@thakares.com (sunil@thakares.com) ---
Regression: Bluetooth broken on MediaTek MT7922 (USB ID 0489:e0d8)
Last working: linux-7.0.6.arch1-1
First broken: linux-7.0.7.arch1-1
Hardware: Lenovo IdeaPad Slim 5 16AHP9 (AMD Ryzen 7 8845HS)
Adapter: Foxconn/Hon Hai BT 5.2 [MediaTek MT7922], USB 0489:e0d8
Symptom: hci0: Failed to send wmt func ctrl (-22), btmgmt shows 0 controllers
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 9:17 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
txxlc@pm.me changed:
What |Removed |Added
----------------------------------------------------------------------------
Bisected commit-id| |634a4408c061
Regression|No |Yes
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 9:15 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
jill+kernel@kokakiwi.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jill+kernel@kokakiwi.net
--- Comment #3 from jill+kernel@kokakiwi.net ---
Confirming this regression on MediaTek MT7922 (`0e8d:0717`) on Arch Linux.
Broken: `7.0.7-zen2-1` (linux-zen) and `6.18.30-1-lts` (linux-lts)
Working: `7.0.6-zen1-1` (linux-zen)
Same symptom: `Bluetooth: hci0: Failed to send wmt func ctrl (-22)` immediately
at boot, Wi-Fi unaffected.
The regression field should be set to "Yes". Based on the 7.0.7 changelog, the
likely culprit is commit `634a4408c061` ("Bluetooth: btmtk: validate WMT event
SKB length before struct access"), which introduced `skb_pull_data()` length
validation in `btmtk_usb_hci_wmt_sync()`. The MT7922 appears to send a WMT
response that the new validation rejects as too short, causing `-EINVAL` before
the chip is ever enabled.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [REGRESSION] MT7925 Bluetooth fails to initialize after btmtk fix 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length")
From: Thorsten Leemhuis @ 2026-05-15 9:07 UTC (permalink / raw)
To: Aaron Muir Hamilton, linux-bluetooth
Cc: regressions, Marcel Holtmann, Tristan Madani,
Luiz Augusto von Dentz, Greg Kroah-Hartman
In-Reply-To: <5i35wmc4z7sz54jo5uj6ywext2enh4ik3oxmfmperqk2v5kc27@ppvm6oodzipn>
On 5/15/26 04:49, Aaron Muir Hamilton wrote:
> 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:
Thx for the report, known issue, we are sorting this out currently. Fix
for it is here:
Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
Ciao, Thorsten
^ permalink raw reply
* Re: Linux 7.1-rc3 regression (Bluetooth)
From: Thorsten Leemhuis @ 2026-05-15 8:56 UTC (permalink / raw)
To: johannes.goede, Greg KH, August Wikerfors
Cc: linux-kernel, linux-bluetooth, Linux kernel regressions list,
stable, Luiz Augusto von Dentz, Pauli Virtanen, Mikhail Gavrilov,
markus.suvanto
In-Reply-To: <7ba6b4ee-fd2a-470e-951c-2c69961b977a@oss.qualcomm.com>
On 5/15/26 09:43, johannes.goede@oss.qualcomm.com wrote:
> On 15-May-26 07:37, Greg KH wrote:
>> 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:
>>>>> 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/
>>> [...]
>>> 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
>>> [...]
>>> 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!
>
> That relies on someone actively intervening in the process though,
> I wonder if it would be an idea to have some CI which checks patches
> in stable RC releases vs regzbot tracking?
>
> This assumes tegzbot tracking includes the mainline git hash of
> commits causing the regression (if/once known).
This is the case. And the idea to let regzbot help with preventing what
happened here is not new and even written on a todo list. The rough plan
was to let regzbot just export the list of mainline commit-ids with
unresolved regressions (together with a link to regzbot's webui with
more details) -- then all Greg would need to do is something like "curl
example.org/unresoved_regressions.txt | grep 1f2e3d4c5b6a" in his apply
script to notice potential problems.
That was how I envisioned things might be good for Greg -- of course
before implementing that I would have talked to him about it. But
regzbot development stalled for about two years due to lack of funding;
we are currently ramping it up again[1], but it will take some time to
get things sorted, so this is likely not something we'll implement
tomorrow. :-(
[1]
https://kernelci.org/blog/2026/05/04/regzbot-joins-kernelci-strengthening-linux-kernel-regression-tracking/
Ciao, Thorsten
^ permalink raw reply
* RE: [net] Bluetooth: ISO: drop ISO_END frames received without prior ISO_START
From: bluez.test.bot @ 2026-05-15 8:54 UTC (permalink / raw)
To: linux-bluetooth, devnexen
In-Reply-To: <20260515062525.57603-1-devnexen@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 937 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=1095152
---Test result---
Test Summary:
CheckPatch PASS 0.73 seconds
GitLint PASS 0.37 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 26.92 seconds
CheckAllWarning PASS 29.66 seconds
CheckSparse PASS 28.48 seconds
BuildKernel32 PASS 26.26 seconds
TestRunnerSetup PASS 577.08 seconds
TestRunner_iso-tester PASS 597.41 seconds
IncrementalBuild PASS 26.05 seconds
https://github.com/bluez/bluetooth-next/pull/194
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v3] Bluetooth: hci_uart: fix UAF in hci_uart_tty_close()
From: bluez.test.bot @ 2026-05-15 8:43 UTC (permalink / raw)
To: linux-bluetooth, w15303746062
In-Reply-To: <20260515065009.383265-1-w15303746062@163.com>
[-- Attachment #1: Type: text/plain, Size: 2497 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=1095160
---Test result---
Test Summary:
CheckPatch FAIL 0.75 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 24.93 seconds
CheckAllWarning PASS 28.01 seconds
CheckSparse PASS 26.42 seconds
BuildKernel32 PASS 24.53 seconds
TestRunnerSetup PASS 527.73 seconds
IncrementalBuild PASS 24.90 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] Bluetooth: hci_uart: fix UAF in hci_uart_tty_close()
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#86:
ODEBUG: free active (active state 0) object: ffff88804024e870 object type: work_struct hint: hci_uart_write_work+0x0/0x940
total: 0 errors, 1 warnings, 21 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14574096.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: hci_uart: fix UAF in hci_uart_tty_close()
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
16: B1 Line exceeds max length (124>80): " ODEBUG: free active (active state 0) object: ffff88804024e870 object type: work_struct hint: hci_uart_write_work+0x0/0x940"
17: B1 Line exceeds max length (86>80): " WARNING: CPU: 0 PID: 338273 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0"
https://github.com/bluez/bluetooth-next/pull/195
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 8:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Piotr Beśka (abuson2@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abuson2@gmail.com
--- Comment #2 from Piotr Beśka (abuson2@gmail.com) ---
I can confirm the same regression on a MediaTek MT7925 PCIe Wi-Fi/Bluetooth
combo adapter.
Working:
* Linux 7.0.6-200.fc44.x86_64
Broken:
* Linux 7.0.7-200.fc44.x86_64
Firmware is unchanged between both tests:
* linux-firmware-20260410-1.fc44.noarch
* mt7xxx-firmware-20260410-1.fc44.noarch
Symptoms match this report:
* Wi-Fi works
* bluetoothd starts
* rfkill shows hci0, not blocked
* bluetoothctl reports: No default controller available
dmesg:
Bluetooth: hci0: Failed to send wmt func ctrl (-22)
Booting back into 7.0.6 immediately restores Bluetooth. A full power cut does
not fix Bluetooth on 7.0.7.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: Linux 7.1-rc3 regression (Bluetooth)
From: johannes.goede @ 2026-05-15 7:43 UTC (permalink / raw)
To: Greg KH, 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: <2026051514-scorch-ecologist-5e7e@gregkh>
Hi,
On 15-May-26 07:37, Greg KH wrote:
> 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!
That relies on someone actively intervening in the process though,
I wonder if it would be an idea to have some CI which checks patches
in stable RC releases vs regzbot tracking?
This assumes tegzbot tracking includes the mainline git hash of
commits causing the regression (if/once known).
Regards,
Hans
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 7:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
txxlc@pm.me changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|blocking |normal
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 7:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
--- Comment #1 from txxlc@pm.me ---
Extra info:
Kernel info:
Linux pc 7.0.7-arch1-1.1 #1 SMP PREEMPT_DYNAMIC Fri, 15 May 2026 00:50:13 +0000
x86_64 GNU/Linux
Hardware:
% lspci -nn | grep -i '03:00.0\|mt7921'
03:00.0 Network controller [0280]: MEDIATEK Corp. MT7921 802.11ax PCIe Wireless
Network Adapter [Filogic 330] [14c3:7961]
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 7:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
txxlc@pm.me changed:
What |Removed |Added
----------------------------------------------------------------------------
Kernel Version| |7.0.7
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 7:03 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
txxlc@pm.me changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|All |AMD
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] New: Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-15 7:01 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Bug ID: 221521
Summary: Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl
(-22) on MediaTek MT7921 combo adapter
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: txxlc@pm.me
Regression: No
On kernel 7.0.7, the Bluetooth portion of the MediaTek MT7921 PCIe combo
adapter fails to initialize. The btusb driver detects the device (hci0), but
initialization aborts with:
Bluetooth: hci0: Failed to send wmt func ctrl (-22)
As a result, bluetoothd starts successfully but reports no available
controllers. bluetoothctl list returns empty, and GUI managers (blueman,
bluedevil) cannot enable the adapter. RFKill shows no software/hardware blocks.
The Wi-Fi portion (mt7921e) initializes and works correctly.
Steps to Reproduce
1. Boot system with kernel 7.0.7
2. Check dmesg | grep -iE 'bluetooth|btusb|mt7921'
3. Run bluetoothctl list
4. Observe Failed to send wmt func ctrl (-22) in kernel log and No default
controller available in BlueZ
Relevant logs:
% sudo dmesg | grep -A2 -B2 'wmt func ctrl'
[ 6.063435] input: HD-Audio Generic Mic as
/devices/pci0000:00/0000:00:08.1/0000:04:00.6/sound/card1/input16
[ 6.063488] input: HD-Audio Generic Headphone as
/devices/pci0000:00/0000:00:08.1/0000:04:00.6/sound/card1/input17
[ 6.078123] Bluetooth: hci0: Failed to send wmt func ctrl (-22)
[ 6.078129] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection
command is advertised, but not supported.
[ 6.133913] mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time:
20260224110909a
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [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