BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 17:55 UTC (Wed) by Liskni_si (guest, #91943)
Parent article: BleedingTooth: critical kernel Bluetooth vulnerability

None of these patches are in 5.8.15 or any other recent stable kernel and I can't find them mentioned anywhere in stable@vger.k.o. Who do we need to ping to make them go to stable?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 18:36 UTC (Wed) by compudj (subscriber, #43335) [Link] (5 responses)

I just informed Greg KH privately about it. He was not made aware of these issues prior to now. What's up with Intel and Google's security disclosure process ?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 20:31 UTC (Wed) by compudj (subscriber, #43335) [Link] (4 responses)

Actually, looking at Linus' master branch (and v5.9), only

commit a2ec905d1e16 ("Bluetooth: fix kernel oops in store_pending_adv_report") appears to have reached upstream.

All fixes from Intel don't even appear in master, even less in v5.9:

https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...

It appears that Intel's security advisory is wrong when saying "Intel recommends updating the Linux kernel to version 5.9 or later."

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 6:32 UTC (Thu) by mkubecek (guest, #130791) [Link]

It's not really surprising that the fixes are not in 5.9 final as they have been applied to bluetooth-next tree, then merged into net-next on September 29th and have been quietly waiting there for the merge window since. As fixes - and even more so as important security ones - they should have been handled via bluetooth and net trees.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 14:30 UTC (Sun) by gotti79 (guest, #142593) [Link] (2 responses)

Thanks for the patches I looked into them and found a issue with one:

https://lore.kernel.org/linux-bluetooth/20200806181714.32...

Here the part
@@ -376,6 +383,8 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct sk_buff *skb,
struct a2mp_amp_assoc_rsp rsp;
rsp.id = req->id;

+ memset(&rsp, 0, sizeof(rsp));
+
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
amp_mgr_put(tmp);

Seems to be wrong as they set rsp.id only to memset it to zero afterwards.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 15:29 UTC (Sun) by Liskni_si (guest, #91943) [Link] (1 responses)

A fix for this was posted 2 days ago: https://lore.kernel.org/linux-bluetooth/20201016180956.70..., together with something that appears to possibly be another important fix.
I see you posted a patch yourself: https://lore.kernel.org/linux-bluetooth/1603008332-8402-1..., perhaps the recipients of that should be directed towards Luiz's thread instead?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 18:29 UTC (Sun) by gotti79 (guest, #142593) [Link]

Seems that I was not the only one who found this somehow wrong. I only reacted as the former patch did go 1:1 into the current stable kernels 4.19.x, 5.4.x.... Which I feel not so good about.

I do some kernel stuff and the stable kernels are not as stable as they were before so instead of complaining and fixing the issues I tried sending a patch to mainline the better idea.

Thanks for the link to the other patch which I will also look into as I need to fix this issue for 5.4.x and 5.9.x at work anyways. I added the information to the kernel mailinglist so other know also of this.