Re: [PATCH] Bluetooth: L2CAP: clear the SDU before the receive callback

[Piyus Kedia]

Sounds good, thanks for taking care of both!

Best,
Piyus

On Fri, Nov 13, 2026 at 9:53 PM Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
>
> Hi Piyus,
>
> On Fri, Nov 13, 2026 at 11:20 AM Piyus Kedia <piyus@xxxxxxxxxxx> wrote:
> >
> > Hi Luiz,
> >
> > Thanks for sharing this!
> >
> > On the double free: that free isn't new. The block this patch replaces
> > already did it,
> >
> > failed:
> >   if (err) {
> >       kfree_skb(skb);
> >       kfree_skb(chan->sdu);
> >
> > with skb NULL by then, and l2cap_reassemble_sdu() has the same block.
> > So if a shared skb can reach the callback, the existing code
> > double-frees in exactly the same way - this patch neither adds that
> > nor fixes it. What it fixes is the use-after-free on chan->sdu.
> >
> > As far as we can tell, it can't be shared here: skb_share_check() only
> > acts when skb->users != 1, and nothing on the ACL receive path takes a
> > reference - the only two skb_get() calls in net/bluetooth are req_skb
> > in hci_core.c and req_rsp in hci_sync.c, both on the HCI command path,
> > and
> > append_skb_frag() doesn't touch skb->users. We may be wrong about
> > that, and if we are, the fix belongs in recv_pkt() rather than in each
> > caller - it frees the caller's skb on one drop path and leaves it on
> > the others. Happy to send a patch for that separately.
> >
> > You're also right that "frees the skb outright" was wrong: recv_pkt()
> > consumes the skb on its success paths and leaves it to the caller on
> > most of the drop paths. I have a v2 ready with that sentence fixed,
> > but the diff is unchanged from v1. Please let us know if you want it
> > posted.
>
> Ive sent a fix the 6lowpan, so no need to respin this, I will add the
> missing Fixes tag that sashiko flagged.