linux-kernel - Re: [PATCH v2] Bluetooth: Shutdown controller after workqueues are flushed or cancelled

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>] [day] [month] [year] [list]

Message-ID: <CAAd53p6BXj_Yxq+8GvDW4eNvbXisz2WK9uf5rcLrCwkMiSB4-g@mail.gmail.com>
Date:   Thu, 5 Aug 2021 15:19:28 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Mattijs Korpershoek <mkorpershoek@...libre.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Bluez <linux-bluetooth@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Bluetooth: Shutdown controller after workqueues are
 flushed or cancelled

[snipped]

> >How? Most of the time the BT controller can't be brought up again
> >after shutdown(), and we need to stop other activities before that.
> >What other reasoning is expected?
>
> See below.
> >
> >Kai-Heng
> >
> >>
> >> >time it's just "Bluetooth: hci0: HCI reset during shutdown failed" in
> >> >dmesg.
>
> In drivers/bluetooth/btusb.c, there are three cases of
>
>         bt_dev_err(hdev, "HCI reset during shutdown failed");
>
> and in btusb_shutdown_intel_new() it has nothing to do with kfree_skb()
> because of IS_ERR(skb).

No, kfree_skb() doesn't gets called in this case. But when that
happens the BT controller won't work anymore.

>
> Feel free to specify why an skb error links to the race you are trying to fix.

The race here is that the btusb_shutdown_intel_new() is trying to
reset the controller while other works like scanning or discovering
are still underway.
So the patch is to ensure that shutdown() callback is invoked after
other works are cancelled.

I think I understand what you are trying to ask, you want to know
where the double kfree_skb() race happens.
I didn't really investigate that because quiesce the other activities
then call shutdown() is the right thing to do and I haven't seen the
kernel splat since.

Kai-Heng

>
> >> >
> >> >Kai-Heng
> >>
> >>
> >> +++ x/net/bluetooth/hci_request.c
> >> @@ -257,8 +257,10 @@ int __hci_req_sync(struct hci_dev *hdev,
> >>                 break;
> >>         }
> >>
> >> -       kfree_skb(hdev->req_skb);
> >> -       hdev->req_skb = NULL;
> >> +       if (!err) {
> >> +               kfree_skb(hdev->req_skb);
> >> +               hdev->req_skb = NULL;
> >> +       }
> >>         hdev->req_status = hdev->req_result = 0;
> >>
> >>         bt_dev_dbg(hdev, "end: err %d", err);