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
