lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <77E07614-6F68-4661-BC6D-2BD610DBD62A@gmail.com>
Date:   Wed, 12 Jun 2019 13:04:57 +0300
From:   Johan Hedberg <johan.hedberg@...il.com>
To:     Bastien Nocera <hadess@...ess.net>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Vasily Khoruzhick <anarsoul@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] Revert "Bluetooth: Align minimum encryption key size for
 LE and BR/EDR connections"

Hi,

On 12 Jun 2019, at 12.38, Bastien Nocera <hadess@...ess.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ