Hi Alex, > When someone attacks the service provider, it creates connection, > authenticates. Then it requests key size of one byte and it identifies > the key with brute force methods. > > After l2cap info req/resp exchange is complete. the attacker sends l2cap > connect with specific PSM. > > In above procedure, there is no chance for the service provider to check > the encryption key size before l2cap_connect(). Because the state of > l2cap chan in conn->chan_l is BT_LISTEN, there is no l2cap chan with the > state of BT_CONNECT or BT_CONNECT2. > > So service provider should check the encryption key size in > l2cap_connect() > > Signed-off-by: Alex Lu <[email protected]> > --- > net/bluetooth/l2cap_core.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c > index ade83e224567..63df961d402d 100644 > --- a/net/bluetooth/l2cap_core.c > +++ b/net/bluetooth/l2cap_core.c > @@ -4150,6 +4150,13 @@ static struct l2cap_chan *l2cap_connect(struct > l2cap_conn *conn, > > if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE) { > if (l2cap_chan_check_security(chan, false)) { > + if (!l2cap_check_enc_key_size(conn->hcon)) { > + l2cap_state_change(chan, BT_DISCONN); > + __set_chan_timer(chan, L2CAP_DISC_TIMEOUT); > + result = L2CAP_CR_SEC_BLOCK; > + status = L2CAP_CS_NO_INFO; > + goto response; > + } > if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) { > l2cap_state_change(chan, BT_CONNECT2); > result = L2CAP_CR_PEND;
I am not following what you are trying to fix here. Can you show this with a btmon trace from an attacking device? Regards Marcel
