netdev - Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Oct 2020 10:36:24 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Sathish Narsimman <sathish.narasimman@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "Bluetooth: Update resolving list when updating
 whitelist"

On Sun, Oct 04, 2020 at 06:59:24PM +0200, Marcel Holtmann wrote:
> Hi Greg,
> 
> >>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> >>>>> breaks all bluetooth connections on my machine.
> >>>>> 
> >>>>> Cc: Marcel Holtmann <marcel@...tmann.org>
> >>>>> Cc: Sathish Narsimman <sathish.narasimman@...el.com>
> >>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist")
> >>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >>>>> ---
> >>>>> 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?

Corrupted white-space issues aside, yes, it works!

I am running 5.9-rc8 with just this change on it and my tracball works
just fine.

> 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.

How would one go about enabling such a hardware feature if they wanted
to?  :)

Anyway, feel free to put:

Tested-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

on the above patch and hopefully get it to Linus for 5.9-final.

thanks,

greg k-h