You are not logged in.
I noticed that after the kernel upgrade I was not able to connect to any paired Bluetooth devices. In addition, no devices show up during discovery.
Downgrading the kernel to linux-6.11.3.arch1-1 fixes the issue.
I am on a Lenovo Yoga 7 14ARP8 with the "Foxconn / Hon Hai Bluetooth 5.2 Adapter [MediaTek MT7922]".
Offline
Online
I'm sorry if that's a dumb question but why would everything up to 6.11.4 work for me and not for others if it were the same issue?
Offline
It's not - the reference was to hint that there's lot of friction around the BT stack and the MT drivers in the 6.11 kernels.
For 6.11.4 there're actually no MT changes, but
commit 98ccd44002d88cbf4edfc4480df532a3da5a013e
Author: Luiz Augusto von Dentz
Date: Wed Oct 2 11:17:26 2024 -0400
Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync
commit 18fd04ad856df07733f5bb07e7f7168e7443d393 upstream.
This checks if the ACL connection remains valid as it could be destroyed
while hci_enhanced_setup_sync is pending on cmd_sync leading to the
following trace:
BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60
Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37
CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
<TASK>
dump_stack_lvl+0x5d/0x80
? hci_enhanced_setup_sync+0x91b/0xa60
print_report+0x152/0x4c0
? hci_enhanced_setup_sync+0x91b/0xa60
? __virt_addr_valid+0x1fa/0x420
? hci_enhanced_setup_sync+0x91b/0xa60
kasan_report+0xda/0x1b0
? hci_enhanced_setup_sync+0x91b/0xa60
hci_enhanced_setup_sync+0x91b/0xa60
? __pfx_hci_enhanced_setup_sync+0x10/0x10
? __pfx___mutex_lock+0x10/0x10
hci_cmd_sync_work+0x1c2/0x330
process_one_work+0x7d9/0x1360
? __pfx_lock_acquire+0x10/0x10
? __pfx_process_one_work+0x10/0x10
? assign_work+0x167/0x240
worker_thread+0x5b7/0xf60
? __kthread_parkme+0xac/0x1c0
? __pfx_worker_thread+0x10/0x10
? __pfx_worker_thread+0x10/0x10
kthread+0x293/0x360
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2f/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 34:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__hci_conn_add+0x187/0x17d0
hci_connect_sco+0x2e1/0xb90
sco_sock_connect+0x2a2/0xb80
__sys_connect+0x227/0x2a0
__x64_sys_connect+0x6d/0xb0
do_syscall_64+0x71/0x140
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 37:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x101/0x160
kfree+0xd0/0x250
device_release+0x9a/0x210
kobject_put+0x151/0x280
hci_conn_del+0x448/0xbf0
hci_abort_conn_sync+0x46f/0x980
hci_cmd_sync_work+0x1c2/0x330
process_one_work+0x7d9/0x1360
worker_thread+0x5b7/0xf60
kthread+0x293/0x360
ret_from_fork+0x2f/0x70
ret_from_fork_asm+0x1a/0x30
Cc: stable@vger.kernel.org
Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync")
Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Greg Kroah-Hartman
commit e63125eec47dcc169cf62a2a56448bec92a0a271
Author: Luiz Augusto von Dentz
Date: Tue Oct 1 11:21:37 2024 -0400
Bluetooth: btusb: Don't fail external suspend requests
[ Upstream commit 610712298b11b2914be00b35abe9326b5dbb62c8 ]
Commit 4e0a1d8b0675
("Bluetooth: btusb: Don't suspend when there are connections")
introduces a check for connections to prevent auto-suspend but that
actually ignored the fact the .suspend callback can be called for
external suspend requests which
Documentation/driver-api/usb/power-management.rst states the following:
'External suspend calls should never be allowed to fail in this way,
only autosuspend calls. The driver can tell them apart by applying
the :c:func:`PMSG_IS_AUTO` macro to the message argument to the
``suspend`` method; it will return True for internal PM events
(autosuspend) and False for external PM events.'
In addition to that align system suspend with USB suspend by using
hci_suspend_dev since otherwise the stack would be expecting events
such as advertising reports which may not be delivered while the
transport is suspended.
Fixes: 4e0a1d8b0675 ("Bluetooth: btusb: Don't suspend when there are connections")
Signed-off-by: Luiz Augusto von Dentz
Tested-by: Kiran K
Signed-off-by: Sasha Levin
commit 4cb9807c9b53bf1e5560420d26f319f528b50268
Author: Luiz Augusto von Dentz
Date: Mon Sep 30 13:26:21 2024 -0400
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
[ Upstream commit 08d1914293dae38350b8088980e59fbc699a72fe ]
rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
Reported-by: syzbot+d7ce59b06b3eb14fd218
Tested-by: syzbot+d7ce59b06b3eb14fd218
Closes: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218
Fixes: 3241ad820dbb ("[Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO")
Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Sasha Levin
For mediatek, still try to disable aspm.
Online
Bluetooth is for me also broken with "6.11.4" and it was fine with "6.11.3".
I've to connect every device twice to get a connection, after suspend/resume cycle I've to repeat it because the connections are not reestablished.
Has already someone reported that to upstream?
I wonder how upstream managed to break it without noticing.
Last edited by hoschi (2024-10-20 13:55:43)
Offline
Offline
Offline
Same issue with my machine. My laptop has a MediaTek chip and bluetooth was working in kernal version 6.11.3.
Offline
For me, Bluetooth on 6.11.4 worked, but autoconnect didn't work, so I had to manually connect my bluetooth headphones via bluetoothctl. I've downgraded my kernel to 6.11.3 and autoconnect works again.
For me, Bluetooth on 6.11.4 worked, but autoconnect didn't work, so I had to manually connect my bluetooth headphones via bluetoothctl. I've downgraded my kernel to 6.11.3 and autoconnect works again.
Same for me. Working but need to manually reconnect, which sometimes took ages. Revert to previous kernel will fix this issue until the patch.
Offline
The issue should be fixed in linux 6.11.4.arch2-1 currently in core-testing.
Offline
The issue should be fixed in linux 6.11.4.arch2-1 currently in core-testing.
I can confirm - upgrading to 6.11.4-zen 2.1 fixed the autoconnect issue for me.
It randomly started working again even with linux-6.11.4.arch1-1 but if it breaks I'll try linux-6.11.4.arch2-1
Offline
For me:
linux-zen-6.11.4. - bluetooth stopped working entirely
linux-zen-6.11.3. - downgrading to this version I could connect mouse and keyboard but headset just didn't work
linux-zen-6.11.2. - fixed all issues with bluetooth
Offline
It's a totally different story for me. I'm still at 6.11.1 main kernel. Anything beyond that leads to bluetooth problems.
What's equally puzzling is that even recent updates to the LTS kernel also causes bluetooth problems for me. The last working LTS kernel is 6.6.52-1.
Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.
Offline
he last working LTS kernel is 6.6.52-1.
https://bbs.archlinux.org/viewtopic.php … 3#p2203463
It's pretty safe to assume that there're multiple blugs on multiple layers being introduced in recent kernels.
Online
Just FYI 6.11.5 was released today and includes a bluetooth fix (suspend here means bluetooth device suspend)
Bluetooth: btusb: Fix not being able to reconnect after suspend
Offline
That patch got backported to Arch yesterday and is already part of 6.11.4-arch2
Offline
Thanks @v1del - i should have phrased it : ... includes the same bluetooth patch as 6.11.4-arch2 has ...
Offline
For me:
linux-zen-6.11.4. - bluetooth stopped working entirely
linux-zen-6.11.3. - downgrading to this version I could connect mouse and keyboard but headset just didn't work
linux-zen-6.11.2. - fixed all issues with bluetooth
Even after upgrading to 6.11.4-arch2 and 6.11.5 I have the identical situation.
So I guess there are still some BT changes (introduced between 6.11.2 and 6.11.3) that need reverting
Offline
So I guess there are still some BT changes (introduced between 6.11.2 and 6.11.3) that need reverting
Are you able to bisect between those two releases to determine the causal commit?
Offline
I had the same problem as the OP, but 6.11-5 finally fixed it for me. Still the same problem with the new LTS kernel though.
Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.
Offline
Still the same problem with the new LTS kernel though.
The LTS equivalent of the fixes is in 6.6.58.
Offline
skunktrader has an intel chip, https://bbs.archlinux.org/profile.php?id=34000
commit 5291ff856d2c5177b4fe9c18828312be30213193
Author: Luiz Augusto von Dentz
Date: Thu Sep 12 12:17:00 2024 -0400
Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
commit b25e11f978b63cb7857890edb3a698599cddb10e upstream.
This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4
("Bluetooth: Always request for user confirmation for Just Works")
always request user confirmation with confirm_hint set since the
likes of bluetoothd have dedicated policy around JUST_WORKS method
(e.g. main.conf:JustWorksRepairing).
CVE: CVE-2024-8805
Cc: vger.kernel.org
Fixes: ba15a58b179e ("Bluetooth: Fix SSP acceptor just-works confirmation without MITM")
Signed-off-by: Luiz Augusto von Dentz
Tested-by: Kiran K
Signed-off-by: Greg Kroah-Hartman
The other BT related commits introduce a new RTL chip and lastly https://github.com/torvalds/linux/commi … 7673323eae looks innocent enough (resp. this would previously have lead to crashes)
Online
skunktrader wrote:So I guess there are still some BT changes (introduced between 6.11.2 and 6.11.3) that need reverting
Are you able to bisect between those two releases to determine the causal commit?
The only machine I have access to with enough oomph to (re)build the kernel multiple times is currently tied up developing some ESP32 firmware. Hopefully I will be able to spend some time over the weekend. I had a look through the (surprising long) changelog for 6.11.3 at https://cdn.kernel.org/pub/linux/kernel … Log-6.11.3 and might try to cherry pick some commits (thanks @seth) before trying a full bisect cycle.
Offline