linux-kernel - Re: possible deadlock in f_midi

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:   Wed, 14 Sep 2022 16:02:25 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Rondreis <linhaoguo86@...il.com>
Cc:     balbi@...nel.org, john@...anate.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: possible deadlock in f_midi_transmit

On Wed, Sep 14, 2022 at 08:49:49PM +0800, Rondreis wrote:
> Hello,
> 
> When fuzzing the Linux kernel driver v6.0-rc4, the following crash was
> triggered.
> 
> HEAD commit: 7e18e42e4b280c85b76967a9106a13ca61c16179
> git tree: upstream
> 
> kernel config: https://pastebin.com/raw/xtrgsXP3
> C reproducer: https://pastebin.com/raw/C1xYEf7Q
> console output: https://pastebin.com/raw/3RLhvQHE
> 
> Basically, in the c reproducer, we use the gadget module to emulate
> attaching a USB device(vendor id: 0x403, product id: 0xff3d, with the
> midi function) and executing some simple sequence of system calls.
> To reproduce this crash, we utilize a third-party library to emulate
> the attaching process: https://github.com/linux-usb-gadgets/libusbgx.
> Just clone this repository, install it, and compile the c
> reproducer with ``` gcc crash.c -lusbgx -lconfig -o crash ``` will do
> the trick.
> 
> I would appreciate it if you have any idea how to solve this bug.
> 
> The crash report is as follows:
> 
> 
> ============================================
> WARNING: possible recursive locking detected
> 6.0.0-rc4+ #20 Not tainted
> --------------------------------------------
> kworker/0:1H/9 is trying to acquire lock:
> ffff888057ed9228 (&midi->transmit_lock){....}-{2:2}, at:
> f_midi_transmit+0x18c/0x1460 drivers/usb/gadget/function/f_midi.c:683
> 
> but task is already holding lock:
> ffff888057ed9228 (&midi->transmit_lock){....}-{2:2}, at:
> f_midi_transmit+0x18c/0x1460 drivers/usb/gadget/function/f_midi.c:683
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>        CPU0
>        ----
>   lock(&midi->transmit_lock);
>   lock(&midi->transmit_lock);
> 
>  *** DEADLOCK ***
> 
>  May be due to missing lock nesting notation

That's a lockdep warning, is this really deadlocking?

If so, I'd recommend asking the midi developers...

thanks,

greg k-h