[BUG] usb: mdc800: possible circular locking dependency between io_lock and minor_rwsem

[CJ <firefly0158@163.com>]

Hi,


I am reporting a lockdep-detected circular locking dependency in the mdc800 USB
driver, triggered by a syzkaller USB reproducer.  The issue is reproducible with
HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux
7.3.0-rc1).


The reproducer connects a synthetic USB device through dummy_hcd that enumerates
as the mdc800 camera, then opens the character device node.  No filesystem or
image input is involved; the trigger is the connect-then-open sequence on a
device that binds to this driver.


Opening the device reaches mdc800_device_open through the USB character-device
file operations, and lockdep reports that the task is acquiring
&mdc800->io_lock while already holding minor_rwsem#2 taken by usb_open.  The
existing dependency chain in the report shows the opposite order, so the two
lock classes are recorded in both orders and lockdep declares a possible
circular dependency.


One possible cause is that the driver's private io_lock is acquired inside the
USB core's file-open path, which already holds the minor rwsem that guards the
driver binding, while another path takes the same two locks the other way
around.  This looks like a lock-ordering problem between a driver-private mutex
and the USB core file-layer lock rather than a use of a single lock.  I am
reporting the ordering as observed; the driver is legacy and possibly unused, so
if the intended fix is to keep the lock order, please treat this as a report of
the deadlock potential only.


This appears to be a recurrence of the syzbot issue whose external id is
1050c0099ec5bfe7ee4e, title "possible deadlock in mdc800_device_open".  It
remains reproducible on v7.3-rc1.


Reproducer:


syz reproducer:
syz_usb_connect(0x2, 0x40, &(0x7f0000000000)=ANY=[@ANYBLOB="12010001000000085f0500a800010000000109022e0001010080320904000004ff00000007050102080000070582030800010705030240000007058402400000"], 0x0)
syz_open_dev$char_usb(0xc, 0xb4, 0x0)


console output: https://pastebin.com/raw/2jB0d1Lm
kernel config: https://pastebin.com/raw/YZiwabxk


Kernel:


HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
           e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)


Let me know if you need more details or testing.


Best regards,
Changjian