Re: [Linux Kernel Bug] possible deadlock in l2cap_chan_connect

[Jiaming Zhang]

Mikhail Gavrilov <mikhail.v.gavrilov@xxxxxxxxx> 于2026年9月29日周二 15:26写道：
>
> 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.
>

Hi Mikhail,

Sure, I will run my reproducer when the v4 patch is out, and report
the test result as soon as possible.

Thank you for your contribution to fix this issue.

Best Regards,
Jiaming Zhang