linux-kernel - Re: [PATCH v2] Bluetooth: Don't initialize msft/aosp when using user channel

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:   Fri, 12 Nov 2021 16:50:08 -0600
From:   Jesse Melhuish <melhuishj@...omium.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Jesse Melhuish <melhuishj@...omium.org>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
        Sonny Sasaka <sonnysasaka@...omium.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2] Bluetooth: Don't initialize msft/aosp when using user channel

Hi Marcel,

No problem, thanks. Happy to extend userchan-tester; do you mind if we
continue reviewing this patch for approval in the meantime so we can
mitigate the issue on our end?

On Thu, Nov 11, 2021 at 12:43 PM Marcel Holtmann <marcel@...tmann.org> wrote:
>
> Hi Jesse,
>
> > A race condition is triggered when usermode control is given to
> > userspace before the kernel's MSFT query responds, resulting in an
> > unexpected response to userspace's reset command.
> >
> > Issue can be observed in btmon:
> > < HCI Command: Vendor (0x3f|0x001e) plen 2                    #3 [hci0]
> >        05 01                                            ..
> > @ USER Open: bt_stack_manage (privileged) version 2.22  {0x0002} [hci0]
> > < HCI Command: Reset (0x03|0x0003) plen 0                     #4 [hci0]
> >> HCI Event: Command Complete (0x0e) plen 5                   #5 [hci0]
> >      Vendor (0x3f|0x001e) ncmd 1
> >       Status: Command Disallowed (0x0c)
> >       05                                               .
> >> HCI Event: Command Complete (0x0e) plen 4                   #6 [hci0]
> >      Reset (0x03|0x0003) ncmd 2
> >       Status: Success (0x00)
> >
> > Signed-off-by: Jesse Melhuish <melhuishj@...omium.org>
> > Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> > Reviewed-by: Sonny Sasaka <sonnysasaka@...omium.org>
> > ---
> >
> > Changes in v2:
> > - Moved guard to the new home for this code.
> >
> > net/bluetooth/hci_sync.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> > index b794605dc882..5f1f59ac1813 100644
> > --- a/net/bluetooth/hci_sync.c
> > +++ b/net/bluetooth/hci_sync.c
> > @@ -3887,8 +3887,10 @@ int hci_dev_open_sync(struct hci_dev *hdev)
> >           hci_dev_test_flag(hdev, HCI_VENDOR_DIAG) && hdev->set_diag)
> >               ret = hdev->set_diag(hdev, true);
> >
> > -     msft_do_open(hdev);
> > -     aosp_do_open(hdev);
> > +     if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
> > +             msft_do_open(hdev);
> > +             aosp_do_open(hdev);
> > +     }
>
> but then you need to do the same on hci_dev_close. Also it would be good to extend userchan-tester with test cases for this.
>
> Regards
>
> Marcel
>