Re: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU

[Luiz Augusto von Dentz]

Hi Michael,

On Mon, May 18, 2026 at 5:27 PM Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
>
> Hi Michael,
>
> On Sun, May 17, 2026 at 9:03 PM Michael Bommarito
> <michael.bommarito@xxxxxxxxx> wrote:
> >
> > On Sun, May 17, 2026 at 9:00 PM Muhammad Bilal <meatuni001@xxxxxxxxx> wrote:
> > > A response counter covering all outbound responses generated per PDU
> > > would close both paths. Something like:
> > >
> > >         int resp_count = 0;
> > >
> > >         /* in the error path: */
> > >         if (err) {
> > >                 if (++resp_count <= L2CAP_SIG_ECHO_BURST) {
> > >                         BT_ERR("Wrong link type (%d)", err);
> > >                         l2cap_sig_send_rej(conn, cmd->ident);
> > >                 }
> > >                 continue;
> > >         }
> > >
> > >         /* existing echo path: */
> > >         if (cmd->code == L2CAP_ECHO_REQ &&
> > >             ++resp_count > L2CAP_SIG_ECHO_BURST) {
> > >                 skb_pull(skb, len);
> > >                 continue;
> > >         }
> > >
> > > Using pr_warn_ratelimited() instead of BT_ERR() in the loop would
> > > also reduce log amplification independent of the skb path.
> >
> > Thanks, good catch on both!  Luiz reminded me about
> > pr_warn_ratelimited before and I missed that again.
> >
> > I'll give others an opportunity to weigh in and then send an updated v2.
>
> Hmm, the spec does not have support limitation though, it just says:
>
> Implementations shall be able to handle the reception of multiple
> commands in an L2CAP packet sent over fixed channel CID 0x0001.
> [] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
>
> Perhaps we should define our Signalling MTU:
>
> Signaling MTU (MTUsig)
>
> The maximum size of command information that the L2CAP layer entity is
> capable of accepting. The MTUsig, refers to the signaling channel only
> and corresponds to the maximum size of a C-frame, omitting the size of
> the Basic L2CAP header. The MTUsig value of a peer is discovered when
> a C-frame that is too large is rejected by the peer.
>
> The minimum MTU seems to be 48, so we could probably use that as a
> limit for the overall packet. If the response exceeds this limit, we
> should reject it as recommended by the spec, but I think we need to
> reject the whole packet rather than the cmd CID.

Just confirmed, the packet as whole needs to be rejected:

When multiple commands are included in an L2CAP packet and the packet
exceeds the signaling MTU (MTUsig) of the receiver, a single
L2CAP_COMMAND_REJECT_RSP packet shall be sent in response. The
identifier shall match the first request command in the L2CAP packet.
If only responses are recognized, the packet shall be silently
discarded.
[] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-692db0dd-8ed5-693f-d300-4fd7af07e340

So we need to reject with L2CAP_REJ_MTU_EXCEEDED.

> > Thanks,
> > Mike
>
>
>
> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz