You are not logged in.
Pages: 1
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
Offline
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.
Offline
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 (Yesterday 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.
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.
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.
Offline
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.
Online
Pages: 1