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] [day] [month] [year] [list]
Message-Id: <99BA793B-E069-4974-8194-5C69616109FA@holtmann.org>
Date:   Thu, 20 Jun 2019 11:25:48 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        Jeremy Cline <jeremy@...ine.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Bluetooth regression breaking BT connection for all 2.0 and older
 devices in 5.0.15+, 5.1.x and master

Hi Greg,

>> First of all this is a known issue and it seems a fix is in the works,
>> but what I do not understand is why the commit causing this has not
>> simply been reverted until the fix is done, esp. for the 5.0.x
>> stable series where this was introduced in 5.0.15.
>> 
>> The problem I'm talking about is commit d5bb334a8e17 ("Bluetooth: Align
>> minimum encryption key size for LE and BR/EDR connections"):
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5bb334a8e171b262e48f378bd2096c0ea458265
>> basically completely breaking all somewhat older (and some current cheap
>> no-name) bluetooth devices:
>> 
>> A revert of this was first proposed on May 22nd:
>> https://lore.kernel.org/netdev/CA+E=qVfopSA90vG2Kkh+XzdYdNn=M-hJN_AptW=R+B5v3HB9eA@mail.gmail.com/T/
>> We are 18 days further now and this problem still exists, including in the
>> 5.0.15+ and 5.1.x stable kernels.
>> 
>> A solution has been suggested: https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/T/#u
>> and at least the Fedora 5.1.4+ kernels now carry this as a temporary fix,
>> but as of today I do not see a fix nor a revert in Torvald's tree yet and
>> neither does there seem to be any fix in the 5.0.x and 5.1.x stable series.
>> 
>> In the mean time we are getting a lot of bug reports about this:
>> https://bugzilla.kernel.org/show_bug.cgi?id=203643
>> https://bugzilla.redhat.com/show_bug.cgi?id=1711468
>> https://bugzilla.redhat.com/show_bug.cgi?id=1713871
>> https://bugzilla.redhat.com/show_bug.cgi?id=1713980
>> 
>> And some reporters:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1713871#c4
>> Are indicating that the Fedora kernels with the workaround included
>> still do not work...
>> 
>> As such I would like to suggest that we just revert the troublesome
>> commit for now and re-add it when we have a proper fix.
> 
> I've now reverted this as it does not seem to be going anywhere anytime
> soon.  After the mess gets sorted out in Linus's tree, if someone could
> send stable@...r the commit ids that should be applied, I will be glad
> to do so.

this took a while to get fixed since some of the is really old code. I just posted a fix that I think covers all corner cases.

https://lore.kernel.org/linux-bluetooth/20190620091731.5823-1-marcel@holtmann.org/T/#u

If I can get a few people to test this, that would be great. Thanks.

Regards

Marcel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ