Re: [PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

["Siwei Zhang" <oss@fourdim.xyz>]

On Wed, May 20, 2026, at 3:40 PM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, May 20, 2026 at 2:57 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> Hi Luiz,
>>
>> On Wed, May 20, 2026, at 2:26 PM, Luiz Augusto von Dentz wrote:
>> > Hi Siwei,
>> >
>> > On Wed, May 20, 2026 at 12:39 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>> >>
>> >> Hi Bluetooth maintainers,
>> >>
>> >> A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28
>> >> by Safa Karakuş. v4 is here:
>> >>
>> >> https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/
>> >>
>> >> I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in
>> >> April 11th. The public patch breaks the embargo and I would like to resend my patch here.
>> >>
>> >> Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
>> >> l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.
>> >
>> > Are your changes on top of Safa's though? That seems a lot cleaner to be honest.
>> >
>>
>> My patch is not on the top of Safa's. The diff looks quite different.
>> I reported both the sk-lifetime UAF and the conn->chan_l list-corruption race
>> privately to the maintainers on April 11th. And patch shortly on April 12th.
>
> I'm afraid it doesn't matter if you reported first or not, Safa's fix
> is much easier to understand. However, there still seems to be an
> issue of calling l2cap_chan_del without holding the conn->lock.
>
>> >> My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
>> >> to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.
>> >
>> > I rather have each issue handled separately though.
>> >
>>
>> I am happy to handle that separately.
>>
>> Could I get a Reported-by on Safa's patch since I reported the underlying issue before the public post?
>>
>> Reported-by: Siwei Zhang <oss@fourdim.xyz>
>
> You can do it yourself, just respond to the thread. Bonus points if
> you add a Tested-by if it actually fixes part of the problem reported.
>
>> I'll send the conn->lock patch (drains accept queue to local list, drops parent sk_lock, acquires conn->lock -> chan_lock in
>> established order) as another patch shortly.
>
> Don't quite like that solution though, we should be dropping locks we
> didn't acquire on the same scope, besides it seem that was doing a lot
> of malabarism, perhaps we could just schedule l2cap_chan_timeout with
> something like this:
>
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index 4ed745a9c2cf..413b1c63602a 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -1529,8 +1529,11 @@ static void l2cap_sock_cleanup_listen(struct
> sock *parent)
>                        state_to_string(chan->state));
>
>                 l2cap_chan_lock(chan);
> -               __clear_chan_timer(chan);
> -               l2cap_chan_close(chan, ECONNRESET);
> +               /* Since we cannot call l2cap_chan_close() without
> +                * chan->conn, schedule its timer to trigger the close and
> +                * cleanup of this channel.
> +                */
> +               __set_chan_timer(chan, 0);
>                 /* l2cap_conn_del() may already have killed this socket
>                  * (it sets SOCK_DEAD); skip the duplicate to avoid a
>                  * double sock_put()/l2cap_chan_put().
>
> Or perhaps it needs to be conditional to having chan->conn since that
> indicates l2cap_chan_del has not run yet, making it safe to use
> __set_chan_timer.

Thanks, that is much cleaner. 

PATCH sent to https://lore.kernel.org/linux-bluetooth/20260520200611.3033410-1-oss@fourdim.xyz/

Best,
Siwei