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  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:   Sun, 4 Oct 2020 18:59:24 +0200
From:   Marcel Holtmann <>
To:     Greg Kroah-Hartman <>
Cc:     Johan Hedberg <>,
        Sathish Narsimman <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        linux-bluetooth <>,
        "open list:NETWORKING [GENERAL]" <>,
Subject: Re: [PATCH] Revert "Bluetooth: Update resolving list when updating

Hi Greg,

>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
>>>>> breaks all bluetooth connections on my machine.
>>>>> Cc: Marcel Holtmann <>
>>>>> Cc: Sathish Narsimman <>
>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist")
>>>>> Signed-off-by: Greg Kroah-Hartman <>
>>>>> ---
>>>>> net/bluetooth/hci_request.c | 41 ++-----------------------------------
>>>>> 1 file changed, 2 insertions(+), 39 deletions(-)
>>>>> This has been bugging me for since 5.9-rc1, when all bluetooth devices
>>>>> stopped working on my desktop system.  I finally got the time to do
>>>>> bisection today, and it came down to this patch.  Reverting it on top of
>>>>> 5.9-rc7 restored bluetooth devices and now my input devices properly
>>>>> work.
>>>>> As it's almost 5.9-final, any chance this can be merged now to fix the
>>>>> issue?
>>>> can you be specific what breaks since our guys and I also think the
>>>> ChromeOS guys have been testing these series of patches heavily.
>>> My bluetooth trackball does not connect at all.  With this reverted, it
>>> all "just works".
>>> Same I think for a Bluetooth headset, can check that again if you really
>>> need me to, but the trackball is reliable here.
>>>> When you run btmon does it indicate any errors?
>>> How do I run it and where are the errors displayed?
>> you can do btmon -w trace.log and just let it run like tcdpump.
> Ok, attached.
> The device is not connecting, and then I open the gnome bluetooth dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
> Any ideas?

the trace file is from -rc7 or from -rc7 with this patch reverted?

I asked, because I see no hint that anything goes wrong. However I have a suspicion if you bisected it to this patch.

diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index e0269192f2e5..94c0daa9f28d 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -732,7 +732,7 @@ static int add_to_white_list(struct hci_request *req,
                return -1;
        /* White list can not be used with RPAs */
-       if (!allow_rpa && !use_ll_privacy(hdev) &&
+       if (!allow_rpa &&
            hci_find_irk_by_addr(hdev, &params->addr, params->addr_type)) {
                return -1;
@@ -812,7 +812,7 @@ static u8 update_white_list(struct hci_request *req)
                /* White list can not be used with RPAs */
-               if (!allow_rpa && !use_ll_privacy(hdev) &&
+               if (!allow_rpa &&
                    hci_find_irk_by_addr(hdev, &b->bdaddr, b->bdaddr_type)) {
                        return 0x00;

If you just do the above, does thing work for you again?

My suspicion is that the use_ll_privacy check is the wrong one here. It only checks if hardware feature is available, not if it is also enabled.



Powered by blists - more mailing lists