https://bugzilla.kernel.org/show_bug.cgi?id=219458 Bug ID: 219458 Summary: bluetooth connection fails after L2CAP: Fix uaf in l2cap_connect patch Product: Drivers Version: 2.5 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: Bluetooth Assignee: linux-bluetooth@xxxxxxxxxxxxxxx Reporter: ghibo@xxxxxxxxxx Regression: No 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 -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
