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

[Michael Bommarito <michael.bommarito@gmail.com>]

l2cap_sig_channel() walks every L2CAP signaling command packed in
one inbound ACL frame and dispatches each to l2cap_bredr_sig_cmd().
The L2CAP_ECHO_REQ handler unconditionally calls

  l2cap_send_cmd(conn, ident, L2CAP_ECHO_RSP, cmd_len, data);

per request, with no per-PDU cap and no per-connection rate limit
anywhere in the path (HCI -> hci_conn -> l2cap_sig_channel ->
l2cap_bredr_sig_cmd).

A peer that packs N L2CAP_ECHO_REQ commands (4 bytes each) into a
single inbound signaling PDU forces the kernel to emit N separate
ACL frames carrying L2CAP_ECHO_RSP.  Measured between two
unmodified upstream kernels over real radio (Intel AX210 attacker,
Intel BE200 target):

  N=1   :    13 B in,    13 B out,  1 ACL frame back,  23 ms wall
  N=4   :    25 B in,    52 B out,  4 ACL frames back, 12 ms wall
  N=16  :    73 B in,   208 B out, 16 ACL frames back, 28 ms wall
  N=48  :   201 B in,   624 B out, 48 ACL frames back, 67 ms wall
  N=168 :   681 B in,  2184 B out, 168 ACL frames back, 220 ms wall

The 10x latency growth at N=168 vs N=1 (220ms vs 23ms) is the
target's signaling work-queue and radio TX queue saturating on the
burst.  A sustained flood (50 inbound PDUs of 168 packed echoes
each) drives ~840 ECHO_RSPs/sec from the target until the kernel's
input ACL queue back-pressures the attacker; during the attack
window the target's BT radio is fully occupied answering echoes
and any other ongoing BT traffic (audio, HID, file transfer) is
starved.  bluetoothd CPU stays at 0% throughout -- the entire path
is kernel-side.

L2CAP signaling channel CID 0x0001 is pre-auth, so no pairing is
required to reach the bug.  Reproducible from any device with a
programmable Bluetooth radio within range of a target running an
unpatched kernel with CONFIG_BT_BREDR=y (effectively every
Linux distribution that ships Bluetooth).

Cap the number of echoes answered per inbound signaling PDU to
L2CAP_SIG_ECHO_BURST (4).  Subsequent ECHO_REQs in the same PDU
are silently dropped.  Legitimate clients (l2ping, BlueZ test
suite, specification-compliant L2CAP) send one ECHO_REQ per PDU
and are unaffected.  Worst-case amplification ratio is now 4:1
per PDU, bounded.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
---
 net/bluetooth/l2cap_core.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 77dec104a9c36..1c1179fddb8ba 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5626,11 +5626,25 @@ static inline void l2cap_sig_send_rej(struct l2cap_conn *conn, u16 ident)
 	l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
 }
 
+/*
+ * Maximum L2CAP_ECHO_REQ commands handled in a single inbound
+ * signaling PDU.  An inbound PDU may legitimately pack multiple
+ * commands, but a peer that packs many L2CAP_ECHO_REQs into one
+ * PDU triggers an N:1 outbound ECHO_RSP storm that saturates the
+ * link's signaling and ACL TX paths.  Cap the number of echoes
+ * answered per inbound PDU to a small burst.  Subsequent ECHO_REQs
+ * in the same PDU are silently dropped; the peer can pace itself
+ * with one ECHO_REQ per PDU (the l2ping shape and the only legit
+ * use that has ever been observed in the wild).
+ */
+#define L2CAP_SIG_ECHO_BURST	4
+
 static inline void l2cap_sig_channel(struct l2cap_conn *conn,
 				     struct sk_buff *skb)
 {
 	struct hci_conn *hcon = conn->hcon;
 	struct l2cap_cmd_hdr *cmd;
+	unsigned int echo_count = 0;
 	int err;
 
 	l2cap_raw_recv(conn, skb);
@@ -5656,6 +5670,13 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
 			continue;
 		}
 
+		if (cmd->code == L2CAP_ECHO_REQ &&
+		    ++echo_count > L2CAP_SIG_ECHO_BURST) {
+			/* Drop excess echoes packed into one PDU. */
+			skb_pull(skb, len);
+			continue;
+		}
+
 		err = l2cap_bredr_sig_cmd(conn, cmd, len, skb->data);
 		if (err) {
 			BT_ERR("Wrong link type (%d)", err);
-- 
2.53.0