In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: do not leak an hci_conn when a second LE connect is rejected<\/p>\n
create_le_conn_complete() decides whether the failed connection is
\nstill pending by comparing it against hci_lookup_le_connect(), which
\nreturns the first LE connection in BT_CONNECT. That is the same
\nconnection only while at most one is pending.<\/p>\n
Two can be pending. Connections created on the passive scan path sit
\nin BT_CONNECT with HCI_CONN_SCANNING set and are invisible to
\nhci_lookup_le_connect() until hci_le_create_conn_sync() clears the
\nflag when their command is issued, so the -EBUSY guard in
\nhci_connect_le() does not prevent a second connection from being
\nqueued while the first is still on the scan path. Whenever two
\nconnections are in BT_CONNECT at once, the lookup may return one
\nconnection while create_le_conn_complete() is reporting the failure
\nof the other; the early exit then drops the error and hci_conn_failed()
\nnever runs on the connection that failed.<\/p>\n
The controller also rejects a second HCI_OP_LE_CREATE_CONN issued
\nwhile another connection creation is still outstanding, per Core Spec
\nVol 4, Part E. The spec calls for Command Disallowed there; the
\nbcm43438 observed here answers with an LMP\/LL error code instead,
\nwhich bt_to_errno() maps to the -EPROTO (-71) in the log below.<\/p>\n
The leaked connection stays in BT_CONNECT forever, and because
\nhci_connect_le() refuses to dial while hci_lookup_le_connect() finds
\nanything, every subsequent attempt to reach any peer fails with
\n-EBUSY and no command reaches the controller at all.<\/p>\n
Seen on a bcm43438 with two BLE peers polled on the same interval
\n(state 5 is BT_CONNECT; both handles are UNSET ones, allocated from
\nthe ida above HCI_CONN_HANDLE_MAX):<\/p>\n
Bluetooth: hci1: Opcode 0x2013 failed: -71<\/p>\n
# hcitool con
\n < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL
\n < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL<\/p>\n
A btmon capture across the next ten minutes of connect attempts
\ncontains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections
\ndo not recover until the adapter is reset. With this change the same
\nscenario fails the rejected connection cleanly and further connects
\nto both peers go through.<\/p>\n
Ask about the connection itself instead of about the device.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: do not leak an hci_conn when a second LE connect is rejected<\/p>\n
create_le_conn_complete() decides whether the failed conne<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25496","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25496","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25496"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25496"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25496"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}