[PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com Cc: stable@vger.kernel.org --- include/net/bluetooth/hci_core.h | 3 --- net/bluetooth/hci_conn.c | 8 -------- 2 files changed, 11 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h index 05b1b96f4d9e..094e61e07030 100644 --- a/include/net/bluetooth/hci_core.h +++ b/include/net/bluetooth/hci_core.h @@ -190,9 +190,6 @@ struct adv_info {
#define HCI_MAX_SHORT_NAME_LENGTH 10
-/* Min encryption key size to match with SMP */ -#define HCI_MIN_ENC_KEY_SIZE 7 - /* Default LE RPA expiry time, 15 minutes */ #define HCI_DEFAULT_RPA_TIMEOUT (15 * 60)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 3cf0764d5793..bd4978ce8c45 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -1276,14 +1276,6 @@ int hci_conn_check_link_mode(struct hci_conn *conn) !test_bit(HCI_CONN_ENCRYPT, &conn->flags)) return 0;
- /* The minimum encryption key size needs to be enforced by the - * host stack before establishing any L2CAP connections. The - * specification in theory allows a minimum of 1, but to align - * BR/EDR and LE transports, a minimum of 7 is chosen. - */ - if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE) - return 0; - return 1; }
Hi Vasily,
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com Cc: stable@vger.kernel.org
let me have a look at this. Maybe there is a missing initialization for older HID devices that we need to handle. Do you happen to have the full btmon binary trace from controller initialization to connection attempt for me?
Are both devices Bluetooth 2.1 or later device that are supporting Secure Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device?
Regards
Marcel
Hi Vasily,
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com Cc: stable@vger.kernel.org
let me have a look at this. Maybe there is a missing initialization for older HID devices that we need to handle. Do you happen to have the full btmon binary trace from controller initialization to connection attempt for me?
Are both devices Bluetooth 2.1 or later device that are supporting Secure Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device?
I am almost certain that you have a Bluetooth 2.0 mouse. I made a really stupid mistake in the key size check logic and forgot to bind it to SSP support. Can you please check the patch that I just send you.
https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtma...
Regards
Marcel
On Wed, May 22, 2019 at 12:08 AM Marcel Holtmann marcel@holtmann.org wrote:
Hi Vasily,
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com Cc: stable@vger.kernel.org
let me have a look at this. Maybe there is a missing initialization for older HID devices that we need to handle. Do you happen to have the full btmon binary trace from controller initialization to connection attempt for me?
Are both devices Bluetooth 2.1 or later device that are supporting Secure Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device?
I am almost certain that you have a Bluetooth 2.0 mouse. I made a really stupid mistake in the key size check logic and forgot to bind it to SSP support. Can you please check the patch that I just send you.
https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtma...
This patch fixes the issue for me. Thanks!
Regards
Marcel
Greg,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
Regards, Vasily
On Thu, May 23, 2019 at 7:52 AM Vasily Khoruzhick anarsoul@gmail.com wrote:
On Wed, May 22, 2019 at 12:08 AM Marcel Holtmann marcel@holtmann.org wrote:
Hi Vasily,
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com Cc: stable@vger.kernel.org
let me have a look at this. Maybe there is a missing initialization for older HID devices that we need to handle. Do you happen to have the full btmon binary trace from controller initialization to connection attempt for me?
Are both devices Bluetooth 2.1 or later device that are supporting Secure Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device?
I am almost certain that you have a Bluetooth 2.0 mouse. I made a really stupid mistake in the key size check logic and forgot to bind it to SSP support. Can you please check the patch that I just send you.
https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtma...
This patch fixes the issue for me. Thanks!
Regards
Marcel
Hi Vasily,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
lets send the RFC patch upstream since it got enough feedback that it fixes the issue.
Regards
Marcel
On Tue, Jun 11, 2019 at 11:36:26PM +0200, Marcel Holtmann wrote:
Hi Vasily,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
lets send the RFC patch upstream since it got enough feedback that it fixes the issue.
According to Hans, the workaround did not work.
So can we just get this reverted so that people's machines go back to working?
thanks,
greg k-h
On Wed, 2019-06-12 at 09:07 +0200, Greg Kroah-Hartman wrote:
On Tue, Jun 11, 2019 at 11:36:26PM +0200, Marcel Holtmann wrote:
Hi Vasily,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
lets send the RFC patch upstream since it got enough feedback that it fixes the issue.
According to Hans, the workaround did not work.
Is it possible that those folks were running Fedora, and using a version of bluetoothd without a fix for using dbus-broker as the D-Bus daemon implementation?
I backported the fix in an update last week: https://bugzilla.redhat.com/show_bug.cgi?id=1711594
So can we just get this reverted so that people's machines go back to working?
thanks,
greg k-h
Hi,
On 12 Jun 2019, at 12.38, Bastien Nocera hadess@hadess.net wrote:
On Wed, 2019-06-12 at 09:07 +0200, Greg Kroah-Hartman wrote:
On Tue, Jun 11, 2019 at 11:36:26PM +0200, Marcel Holtmann wrote:
Hi Vasily,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
lets send the RFC patch upstream since it got enough feedback that it fixes the issue.
According to Hans, the workaround did not work.
Is it possible that those folks were running Fedora, and using a version of bluetoothd without a fix for using dbus-broker as the D-Bus daemon implementation?
I backported the fix in an update last week: https://bugzilla.redhat.com/show_bug.cgi?id=1711594
I don’t know if that’s the case, but at least based on the comment here:
https://bugzilla.kernel.org/show_bug.cgi?id=203643#c10
it looks like there’s still a race with controllers that do support reading the encryption key size. The peer device may send an L2CAP Connect Request before we’ve completed reading the key size, in which case we’d still reject the request. For making this work again I’m not aware of any other quick solution than a revert.
Johan
On Tue, Jun 11, 2019 at 12:56:02PM -0700, Vasily Khoruzhick wrote:
Greg,
Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month.
Now reverted as the bluetooth developers seem to be moving pretty slowly on this :(
greg k-h
linux-stable-mirror@lists.linaro.org
-
Bastien Nocera -
Greg Kroah-Hartman -
Johan Hedberg -
Marcel Holtmann -
Vasily Khoruzhick