[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

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

[Oliver Neukum]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]



On 14.09.26 09:36, 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.

Hi,

please try the attached patch.

	Regards
		Oliver

[-- Attachment #2: 0001-usb-misc-mdc800-avoid-circular-locking.patch --]
[-- Type: text/x-patch, Size: 1952 bytes --]

From 01e4a5b7f215b5f69ec1fdde829c1cd09498a22f Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Wed, 16 Sep 2026 17:37:25 +0200
Subject: [PATCH] usb: misc: mdc800: avoid circular locking

No need for locking in probe()

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/image/mdc800.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/image/mdc800.c b/drivers/usb/image/mdc800.c
index f7caa1c5cbb7..9edf0afe8dad 100644
--- a/drivers/usb/image/mdc800.c
+++ b/drivers/usb/image/mdc800.c
@@ -480,15 +480,6 @@ static int mdc800_usb_probe (struct usb_interface *intf,
 
 	dev_info(&intf->dev, "Found Mustek MDC800 on USB.\n");
 
-	mutex_lock(&mdc800->io_lock);
-
-	retval = usb_register_dev(intf, &mdc800_class);
-	if (retval) {
-		dev_err(&intf->dev, "Not able to get a minor for this device.\n");
-		mutex_unlock(&mdc800->io_lock);
-		return -ENODEV;
-	}
-
 	mdc800->dev=dev;
 	mdc800->open=0;
 
@@ -526,7 +517,11 @@ static int mdc800_usb_probe (struct usb_interface *intf,
 
 	mdc800->state=READY;
 
-	mutex_unlock(&mdc800->io_lock);
+	retval = usb_register_dev(intf, &mdc800_class);
+	if (retval) {
+		dev_err(&intf->dev, "Not able to get a minor for this device.\n");
+		return -ENODEV;
+	}
 	
 	usb_set_intfdata(intf, mdc800);
 	return 0;
@@ -548,15 +543,12 @@ static void mdc800_usb_disconnect (struct usb_interface *intf)
 
 		usb_deregister_dev(intf, &mdc800_class);
 
-		/* must be under lock to make sure no URB
-		   is submitted after usb_kill_urb() */
-		mutex_lock(&mdc800->io_lock);
 		mdc800->state=NOT_CONNECTED;
 
-		usb_kill_urb(mdc800->irq_urb);
-		usb_kill_urb(mdc800->write_urb);
-		usb_kill_urb(mdc800->download_urb);
-		mutex_unlock(&mdc800->io_lock);
+		usb_poison_urb(mdc800->irq_urb);
+		usb_poison_urb(mdc800->write_urb);
+		usb_poison_urb(mdc800->download_urb);
+
 
 		mdc800->dev = NULL;
 		usb_set_intfdata(intf, NULL);
-- 
2.55.0