When an l2cap channel receives L2CAP_CONN_RSP, it revives from BT_DISCONN
to BT_CONFIG or BT_CONNECTED.
It is very weird, violates the specification, and I cannot see any real
usecase for this.
Similar to this, the L2cap channel has six illegal state transitions:
1. BT_CONNECT2 -> BT_CONFIG by L2CAP_CONN_RSP
2. BT_CONNECT2 -> BT_CONNECTED by L2CAP_CONF_RSP
3. BT_CONNECT2 -> BT_DISCONN by L2CAP_CONF_RSP
4. BT_CONNECTED -> BT_CONFIG by L2CAP_CONN_RSP
5. BT_DISCONN -> BT_CONFIG by L2CAP_CONN_RSP
6. BT_DISCONN -> BT_CONNECTED by L2CAP_CONN_RSP
This patch fixes 2, 3, 5, and 6 by adding checks.
For 1 and 4, I will make an RFC for as it requires some refactoring.
The detaild logs are described in here:
https://lore.kernel.org/lkml/CAJNyHpKpDdps4=QHZ77zu4jfY-NNBcGUrw6UwjuBKfpuSuE__g@mail.gmail.com/
Signed-off-by: Sungwoo Kim <[email protected]>
---
net/bluetooth/l2cap_core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 60298975d..c5fa2b683 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4339,6 +4339,14 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
l2cap_chan_lock(chan);
+ switch (chan->state) {
+ case BT_CLOSED:
+ case BT_DISCONN:
+ l2cap_chan_unlock(chan);
+ l2cap_chan_put(chan);
+ goto unlock;
+ }
+
switch (result) {
case L2CAP_CR_SUCCESS:
if (__l2cap_get_chan_by_dcid(conn, dcid)) {
@@ -4552,6 +4560,14 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
if (!chan)
return 0;
+ switch (chan->state) {
+ case BT_CLOSED:
+ case BT_CONNECT:
+ case BT_CONNECT2:
+ case BT_DISCONN:
+ goto done;
+ }
+
switch (result) {
case L2CAP_CONF_SUCCESS:
l2cap_conf_rfc_get(chan, rsp->data, len);
--
2.25.1