Re: [Linux Kernel Bug] possible deadlock in l2cap_chan_connect

[Mikhail Gavrilov]

On Fri, Sep 11, 2026 at 11:38 PM Ali Ahmet Memiş <aliamemis@xxxxxxxxxxx> wrote:
>
> On Sat, Sep 12, 2026 at 12:59:09AM +0800, Jiaming Zhang wrote:
> > We are actively working on a patch, if the above solution is acceptable,
> > I would be happy to submit a formal patch for review.
>
> This is the same lock inversion syzbot reported as 74071deb, and Mikhail
> already has a fix for it under review:
>
>   https://lore.kernel.org/linux-bluetooth/20260904012028.77590-1-mikhail.v.gavrilov@xxxxxxxxx/
>
> It uses the same approach you describe, queue the confirmation and let
> krfcommd handle it under rfcomm_mutex.

Hi Jiaming, Ali,

thanks for the report and for putting the reproducer up, and thanks
Ali for connecting the two threads.

The deferral Jiaming suggests is what v2 of my patch did - that is the
version Ali linked - but that approach was dropped during review.  Pauli
pointed out that delaying the confirmation makes it hard to rule out new
races against DLC setup, and Luiz asked to break the cycle on the connect
side instead.

v3 does that.  The session socket is created and connected without
rfcomm_mutex held, and the lock is only taken again to put the new
session on the list:

  https://lore.kernel.org/linux-bluetooth/20260912100315.151674-1-mikhail.v.gavrilov@xxxxxxxxx/

That removes exactly the edge in your trace, rfcomm_dlc_open() holding
rfcomm_mutex while l2cap_chan_connect() takes hdev->lock.  syzbot's own
reproducer no longer triggers with it:

  https://lore.kernel.org/all/6ab100d7.71f81b7d.15fa6d.0029.GAE@xxxxxxxxxx/

v4 will follow shortly.  It adds a check for the socket being closed while
it is being connected, which Luiz and the Sashiko review raised on v3.
I will Cc you and add your report as Reported-by and Closes.

Could you run your C reproducer against v4 once it is out?  A Tested-by
from your side would be worth a lot, since your trace hits the cycle from
the connect side, which is the edge the patch removes.

-- 
Thanks,
Mikhail