Bluetooth: Fix accepting early data on fixed channels

On BR/EDR the L2CAP channel instances for fixed channels have so far
been marked as ready only once the L2CAP information req/rsp procedure
is complete and we have the fixed channel mask. This could however lead
to data being dropped if we receive it on the channel before knowing the
remote mask.

Since it is valid for a remote to send data this early, simply assume
that the channel is supported when we receive data on it. So far this
hasn't been noticed much because of limited use of fixed channels on
BR/EDR, but e.g. with SMP over BR/EDR this is already now visible with
automated tests failing randomly.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 6ba33f9631e8e5830374ab4e51720c493969c67c..ec6f78e481dc5da8110c47a8acd422c294b21b8f 100644 (file)
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1244,6 +1244,13 @@ static void l2cap_move_done(struct l2cap_chan *chan)
 
 static void l2cap_chan_ready(struct l2cap_chan *chan)
 {
+       /* The channel may have already been flagged as connected in
+        * case of receiving data before the L2CAP info req/rsp
+        * procedure is complete.
+        */
+       if (chan->state == BT_CONNECTED)
+               return;
+
        /* This clears all conf flags, including CONF_NOT_COMPLETE */
        chan->conf_state = 0;
        __clear_chan_timer(chan);
@@ -6785,6 +6792,13 @@ static void l2cap_data_channel(struct l2cap_conn *conn, u16 cid,
 
        BT_DBG("chan %p, len %d", chan, skb->len);
 
+       /* If we receive data on a fixed channel before the info req/rsp
+        * procdure is done simply assume that the channel is supported
+        * and mark it as ready.
+        */
+       if (chan->chan_type == L2CAP_CHAN_FIXED)
+               l2cap_chan_ready(chan);
+
        if (chan->state != BT_CONNECTED)
                goto drop;