linux-6.11.4.arch1-1 breaks bluetooth

petauristini · Yesterday 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 · Yesterday 11:34:17

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

petauristini · Yesterday 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 · Yesterday 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 · Yesterday 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 (Yesterday 13:55:43)

loqs · Yesterday 13:58:47

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

hoschi · Yesterday 14:01:29

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

Ate329 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 20:26:07

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

thoushaltnot · Today 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 · Today 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

Arch Linux

#1 Yesterday 10:46:22

linux-6.11.4.arch1-1 breaks bluetooth

#2 Yesterday 11:34:17

Re: linux-6.11.4.arch1-1 breaks bluetooth

#3 Yesterday 12:56:39

Re: linux-6.11.4.arch1-1 breaks bluetooth

#4 Yesterday 13:07:34

Re: linux-6.11.4.arch1-1 breaks bluetooth

#5 Yesterday 13:49:44

Re: linux-6.11.4.arch1-1 breaks bluetooth

#6 Yesterday 13:58:47

Re: linux-6.11.4.arch1-1 breaks bluetooth

#7 Yesterday 14:01:29

Re: linux-6.11.4.arch1-1 breaks bluetooth

#8 Yesterday 14:32:45

Re: linux-6.11.4.arch1-1 breaks bluetooth

#9 Yesterday 18:00:37

Re: linux-6.11.4.arch1-1 breaks bluetooth

#10 Yesterday 19:47:26

Re: linux-6.11.4.arch1-1 breaks bluetooth

#11 Yesterday 20:26:07

Re: linux-6.11.4.arch1-1 breaks bluetooth

#12 Today 06:14:14

Re: linux-6.11.4.arch1-1 breaks bluetooth

#13 Today 07:53:14

Re: linux-6.11.4.arch1-1 breaks bluetooth

Board footer