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

Date:   Wed, 14 Sep 2022 22:42:55 +0800
From:   Rondreis <linhaoguo86@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
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

Happy to receive your reply! I will double-check its validity. If
there is still a problem, I will contact the midi development team.

Best wishes!
Rondreis

On Wed, Sep 14, 2022 at 10:02 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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