2011-08-24 14:05:09

by Peter Hurley

[permalink] [raw]
Subject: [RFC v3 4/4] Bluetooth: l2cap: fix NULL ACL packet handling

A 0-length ACL continuation-fragment is a valid NULL packet. Remote
devices can use the FLOW indicator in the ACL packet header to
flow-control ACL packets without sending a payload.

Track as a connection stat instead of logging.
---

v2 ensure the fragment is 0-length
v3 use new hci_conn.stats rather than hci_dev.stat

net/bluetooth/l2cap_core.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 2969ef0..67a3342 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4120,6 +4120,14 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
BT_DBG("Cont: frag len %d (expecting %d)", skb->len, conn->rx_len);

if (!conn->rx_len) {
+ /* A 0-length, continuation fragment is a NULL packet
+ * (Core 2.1, Vol 2, Part B, 6.5.1.2, 6.4.3 & 6.6.2)
+ * The remote device is likely controlling packet flow
+ * with ACL payload header FLOW indicator. */
+ if (!skb->len) {
+ hcon->stats.null_rx++;
+ goto drop;
+ }
BT_ERR("Unexpected continuation frame (len %d)", skb->len);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
--
1.7.4.1