[Bug 219458] New: bluetooth connection fails after L2CAP: Fix uaf in l2cap_connect patch

[bugzilla-daemon@kernel.org]

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@vger.kernel.org
          Reporter: ghibo@mageia.org
        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.