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

[Muhammad Bilal]

Hi Michael,

Thanks for the patch. The ECHO_REQ cap addresses one amplification
vector, but the same N:1 amplification appears reachable via the
unknown-command path in the same loop.

When l2cap_bredr_sig_cmd() returns an error for an unrecognised command
code, the loop calls l2cap_sig_send_rej() unconditionally:

        err = l2cap_bredr_sig_cmd(conn, cmd, len, skb->data);
        if (err) {
                BT_ERR("Wrong link type (%d)", err);
                l2cap_sig_send_rej(conn, cmd->ident);
        }

A peer that packs N commands with an unknown code (e.g. 0xFF, len = 0)
into a single signaling PDU would trigger N calls to
l2cap_sig_send_rej(), sending N COMMAND_REJ responses,
bypassing the new L2CAP_SIG_ECHO_BURST limit entirely. This produces
the same TX queue saturation the patch intends to prevent, and also
floods the kernel log with N BT_ERR() writes per PDU.

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.

Regards,
Muhammad Bilal