Hi guys. After a recent kernel update I get problems in bluetooth connectivity. Mostly some bluetooth audio devices (like speakers or headphones) are getting very difficult to connect, even if already paired. And when the connection is finally established they do not seem to do it in the correct way, to the extent that the devices are not later correctly attached to pulseaudio or pipewire, and not listed there. I thought the problem could be in bluez's bluetoothd, so I tried several version of bluez, up to 5.78, including the current git version, but mostly the behaviour hadn't changed. I noticed this behaviour in 6.6.59 (including up to the current stable-queue for 6.6.59 as of today, which will be merged into next 6.6.60). Ditto for kernel series 6.11.x, in particular 6.11.5 and 6.11.6 show the same behaviour. After a long series of attempts, I found the culprit can be traced back to these single patch with subject "Bluetooth: L2CAP: Fix uaf in l2cap_connect": https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/releases/6.6.55/bluetooth-l2cap-fix-uaf-in-l2cap_connect.patch and https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/releases/6.11.3/bluetooth-l2cap-fix-uaf-in-l2cap_connect.patch which were included starting from kernels 6.6.55 and 6.11.3. By reverting this patch, the connection with the device gets back working again like a breeze, either at connecting and disconnecting several times in a row, while before this reverting the connection was pretty clumsy. Apparently this patch was for a security fix, but probably it's still incomplete, as there is this side effect. Difficult to track in logs, as logsa are pretty verbose anyway, as even in a situation where a connection working there are a lot of warnings; mostly in a broken connection with the patch included, logs are like: bluetoothd[10741]: Failed to set mode: Failed (0x03) bluetoothd[10741]: No matching connection for device bluetoothd[10741]: No matching connection for device while in a working connection, with the patch reverted, logs are like: bluetoothd[10863]: Failed to set mode: Failed (0x03) ... bluetoothd[10863]: No matching connection for device ... bluetoothd[10863]: /org/bluez/hci0/dev_<mac_address>/sep2/fd2: fd(42) ready
(In reply to Giuseppe Ghibò from comment #0) > Difficult to track in logs, as logsa are pretty verbose anyway, as even in a > situation where a connection working there are a lot of warnings; mostly in > a broken connection with the patch included, logs are like: > > bluetoothd[10741]: Failed to set mode: Failed (0x03) > bluetoothd[10741]: No matching connection for device > bluetoothd[10741]: No matching connection for device > > while in a working connection, with the patch reverted, logs are like: > > bluetoothd[10863]: Failed to set mode: Failed (0x03) > ... > bluetoothd[10863]: No matching connection for device > ... > bluetoothd[10863]: /org/bluez/hci0/dev_<mac_address>/sep2/fd2: fd(42) ready Could you please attach the btmon trace when this happens?
Created attachment 307181 [details] btmon output (connection working)
Created attachment 307182 [details] btmon output (connection not working)
btmon output added. As you can see in the working case the behaviour diverges from packet #16 (in the first case, working) and after packet #94 in the "not working" case, both calls ACL Data RX with L2CAP: Information Request:, but in the working case it's followed by HCI Event: Read Remote... and other commands, while in the not working case it's immediately followed by "MGMT Event: Device Connected", like if something was truncated. [working] > ACL Data RX: Handle 256 flags 0x02 dlen 10 #16 [hci0] 413.700565 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Read Remote Extended Featu.. (0x23) plen 13 #17 [hci0] 413.700588 [not working] > ACL Data RX: Handle 256 flags 0x02 dlen 10 #94 [hci0] 20.205711 L2CAP: Information Request (0x0a) ident 7 len 2 Type: Extended features supported (0x0002) @ MGMT Event: Device Connected (0x000b) plen 13 {0x0001} [hci0] 20.205764 BR/EDR Address: AA:BB:CC:DD:EE:FF (Company)
Created attachment 307186 [details] Bluetooth: hci_core: Fix calling mgmt_device_connected Please try with the following patch.
(In reply to Giuseppe Ghibò from comment #4) > btmon output added. As you can see in the working case the behaviour > diverges from packet #16 (in the first case, working) and after packet #94 > in the "not working" case, both calls ACL Data RX with L2CAP: Information > Request:, but in the working case it's followed by HCI Event: Read Remote... > and other commands, while in the not working case it's immediately followed > by "MGMT Event: Device Connected", like if something was truncated. > > [working] > > ACL Data RX: Handle 256 flags 0x02 dlen 10 #16 [hci0] > 413.700565 > L2CAP: Information Request (0x0a) ident 1 len 2 > Type: Extended features supported (0x0002) > > HCI Event: Read Remote Extended Featu.. (0x23) plen 13 #17 [hci0] > 413.700588 > > > [not working] > > ACL Data RX: Handle 256 flags 0x02 dlen 10 #94 [hci0] > 20.205711 > L2CAP: Information Request (0x0a) ident 7 len 2 > Type: Extended features supported (0x0002) > @ MGMT Event: Device Connected (0x000b) plen 13 {0x0001} [hci0] > 20.205764 > BR/EDR Address: AA:BB:CC:DD:EE:FF (Company) Any chance to check with the patch above?
Hi Luiz I can check the patch. I ran on the same problem (when Updating from 6.6.52 to 6.6.58 on Gentoo) and I submitted a bug report there. They asked me to do a git bisect of linux-vanilla and my bisect also reported that patch. I'll try applying the patch and let you know if this solves the problem for me.
(In reply to Luiz Von Dentz from comment #6) > (In reply to Giuseppe Ghibò from comment #4) > > btmon output added. As you can see in the working case the behaviour > > diverges from packet #16 (in the first case, working) and after packet #94 > > in the "not working" case, both calls ACL Data RX with L2CAP: Information > > Request:, but in the working case it's followed by HCI Event: Read > Remote... > > and other commands, while in the not working case it's immediately followed > > by "MGMT Event: Device Connected", like if something was truncated. > > > > [working] > > > ACL Data RX: Handle 256 flags 0x02 dlen 10 #16 [hci0] > > 413.700565 > > L2CAP: Information Request (0x0a) ident 1 len 2 > > Type: Extended features supported (0x0002) > > > HCI Event: Read Remote Extended Featu.. (0x23) plen 13 #17 [hci0] > > 413.700588 > > > > > > [not working] > > > ACL Data RX: Handle 256 flags 0x02 dlen 10 #94 [hci0] > > 20.205711 > > L2CAP: Information Request (0x0a) ident 7 len 2 > > Type: Extended features supported (0x0002) > > @ MGMT Event: Device Connected (0x000b) plen 13 {0x0001} [hci0] > > 20.205764 > > BR/EDR Address: AA:BB:CC:DD:EE:FF (Company) > > Any chance to check with the patch above? Yes, just finished applying the patch (and not reverting the previous) to current 6.6.60+stable-queue as of today, and it didn't show the previous problem anymore.
Hi Luiz Like Guiseppe, on 6.6.58 I didn't revert the original commit and applied the patch (thus removing only the if clause and the mgmt_device_connected call) and it seems that the problem is gone. I was able to connect and disconnect multiple times in succession, I was able to remove my USB-Bluetooth device and insert it again and was able to connect again, I tried that several times and it always worked. Now it seems fine.
Patch has been applied to bluetooth-next, pull-request in its way: https://patchwork.kernel.org/project/bluetooth/patch/20241112175326.930800-1-luiz.dentz@gmail.com/
I've seen this patch is now included in 6.6.621, 6.11.9, 6.12.0. Thanks. Closing.
Of course 6.6.62 not 6.6.621.