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

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

[CJ]

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

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

[Greg KH]

On Mon, Sep 14, 2026 at 03:36:36PM +0800, CJ wrote:
> 
> 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.

Great, can you provide fixes for this, and the other reports you just
sent out?  Otherwise there's not much we really can do with this at the
moment as we are drowning in real fixes, and probably don't have time to
spend on reports-only.

thanks,

greg k-h