netdev - Re: [PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"

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]

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