netdev - Re: [syzbot] BUG: sleeping function called from invalid context in hci_cmd_sync

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

Date:   Thu, 9 Dec 2021 14:21:20 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Benjamin Berg <bberg@...hat.com>, Oliver Neukum <oneukum@...e.com>,
        syzbot <syzbot+485cc00ea7cf41dfdbf1@...kaller.appspotmail.com>,
        Thinh.Nguyen@...opsys.com, changbin.du@...el.com,
        christian.brauner@...ntu.com, davem@...emloft.net,
        edumazet@...gle.com, gregkh@...uxfoundation.org,
        johan.hedberg@...il.com, kuba@...nel.org,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, luiz.dentz@...il.com,
        luiz.von.dentz@...el.com, marcel@...tmann.org,
        mathias.nyman@...ux.intel.com, netdev@...r.kernel.org,
        stern@...land.harvard.edu, syzkaller-bugs@...glegroups.com,
        yajun.deng@...ux.dev
Subject: Re: [syzbot] BUG: sleeping function called from invalid context in
 hci_cmd_sync_cancel


On 09.12.21 13:46, Benjamin Berg wrote:
Hi,
> On Thu, 2021-12-09 at 11:06 +0100, Oliver Neukum wrote:
>> As __cancel_work_timer can be called from hci_cmd_sync_cancel() this is
>> just not
>> an approach you can take. It looks like asynchronously canceling the
>> scheduled work
>> would result in a race, so I would for now just revert.
> Right, so this needs to be pushed into a workqueue instead, I suppose.
It looks like overkill, but I have no good alternative to offer either.
>
>> What issue exactly is this trying to fix or improve?
> The problem is aborting long-running synchronous operations. i.e.
> without this patchset, USB enumeration will hang for 10s if a USB
> bluetooth device disappears during firmware loading. This is because
> even though the USB device is gone and all URB submissions fail, the
> operation will only be aborted after the internal timeout happens.
>
I see. Something ought to be done. The issue is in good hands.

    Thanks
        Oliver