linux-6.11.4.arch1-1 breaks bluetooth

petauristini · 2024-10-20 10:46:22

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]".

seth · 2024-10-20 11:34:17

https://bbs.archlinux.org/viewtopic.php … 4#p2203434

petauristini · 2024-10-20 12:56:39

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?

seth · 2024-10-20 13:07:34

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.

hoschi · 2024-10-20 13:49:44

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)

loqs · 2024-10-20 13:58:47

https://bbs.archlinux.org/viewtopic.php … 2#p2203662

hoschi · 2024-10-20 14:01:29

https://lore.kernel.org/all/CABBYNZL0_j … gmail.com/

Ate329 · 2024-10-20 14:32:45

Same issue with my machine. My laptop has a MediaTek chip and bluetooth was working in kernal version 6.11.3.

thoushaltnot · 2024-10-20 18:00:37

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.

mobal · 2024-10-20 19:47:26

thoushaltnot wrote:

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.

loqs · 2024-10-20 20:26:07

The issue should be fixed in linux 6.11.4.arch2-1 currently in core-testing.

thoushaltnot · 2024-10-21 06:14:14

loqs wrote:

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.

petauristini · 2024-10-21 07:53:14

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

vavra.7 · 2024-10-21 10:01:54

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

kermit63 · 2024-10-21 10:26:33

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.

seth · 2024-10-21 11:38:38

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.

GeneArch · 2024-10-22 15:37:07

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

V1del · 2024-10-22 15:44:23

That patch got backported to Arch yesterday and is already part of 6.11.4-arch2

GeneArch · 2024-10-22 15:57:20

Thanks @v1del - i should have phrased it : ... includes the same bluetooth patch as 6.11.4-arch2 has ...

skunktrader · 2024-10-23 00:21:24

vavra.7 wrote:

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

loqs · 2024-10-23 00:36:00

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?

kermit63 · 2024-10-23 03:17:02

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.

loqs · 2024-10-23 04:34:20

kermit63 wrote:

Still the same problem with the new LTS kernel though.

The LTS equivalent of the fixes is in 6.6.58.

seth · 2024-10-23 07:06:33

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)

skunktrader · 2024-10-24 00:03:15

loqs wrote:

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.

Arch Linux

#1 2024-10-20 10:46:22

linux-6.11.4.arch1-1 breaks bluetooth

#2 2024-10-20 11:34:17

Re: linux-6.11.4.arch1-1 breaks bluetooth

#3 2024-10-20 12:56:39

Re: linux-6.11.4.arch1-1 breaks bluetooth

#4 2024-10-20 13:07:34

Re: linux-6.11.4.arch1-1 breaks bluetooth

#5 2024-10-20 13:49:44

Re: linux-6.11.4.arch1-1 breaks bluetooth

#6 2024-10-20 13:58:47

Re: linux-6.11.4.arch1-1 breaks bluetooth

#7 2024-10-20 14:01:29

Re: linux-6.11.4.arch1-1 breaks bluetooth

#8 2024-10-20 14:32:45

Re: linux-6.11.4.arch1-1 breaks bluetooth

#9 2024-10-20 18:00:37

Re: linux-6.11.4.arch1-1 breaks bluetooth

#10 2024-10-20 19:47:26

Re: linux-6.11.4.arch1-1 breaks bluetooth

#11 2024-10-20 20:26:07

Re: linux-6.11.4.arch1-1 breaks bluetooth

#12 2024-10-21 06:14:14

Re: linux-6.11.4.arch1-1 breaks bluetooth

#13 2024-10-21 07:53:14

Re: linux-6.11.4.arch1-1 breaks bluetooth

#14 2024-10-21 10:01:54

Re: linux-6.11.4.arch1-1 breaks bluetooth

#15 2024-10-21 10:26:33

Re: linux-6.11.4.arch1-1 breaks bluetooth

#16 2024-10-21 11:38:38

Re: linux-6.11.4.arch1-1 breaks bluetooth

#17 2024-10-22 15:37:07

Re: linux-6.11.4.arch1-1 breaks bluetooth

#18 2024-10-22 15:44:23

Re: linux-6.11.4.arch1-1 breaks bluetooth

#19 2024-10-22 15:57:20

Re: linux-6.11.4.arch1-1 breaks bluetooth

#20 2024-10-23 00:21:24

Re: linux-6.11.4.arch1-1 breaks bluetooth

#21 2024-10-23 00:36:00

Re: linux-6.11.4.arch1-1 breaks bluetooth

#22 2024-10-23 03:17:02

Re: linux-6.11.4.arch1-1 breaks bluetooth

#23 2024-10-23 04:34:20

Re: linux-6.11.4.arch1-1 breaks bluetooth

#24 2024-10-23 07:06:33

Re: linux-6.11.4.arch1-1 breaks bluetooth

#25 2024-10-24 00:03:15

Re: linux-6.11.4.arch1-1 breaks bluetooth

Board footer