[bug report] Potential order bug in 'drivers/usb/misc/ldusb.c', mainly in 'ld_usb_disconnect()'

[bug report] Potential order bug in 'drivers/usb/misc/ldusb.c', mainly in 'ld_usb_disconnect()'

[Ginger]

Dear Linux kernel maintainers,

My research-based static analyzer found a potential order bug within
the 'drivers/usb/misc' subsystem, more specifically, in
'drivers/usb/misc/ldusb.c'.

This potential issue is similar to a previously reported one
(https://lore.kernel.org/linux-usb/2026042444-freeing-consumer-468b@gregkh/).
It is present as of git commit eb3f4b7426cfd2b79d65b7d37155480b32259a11.

Potential concurrent triggering executions:
T0:
ld_usb_disconnect
    --> usb_set_intfdata(interface, NULL); [t0]
    --> usb_deregister_dev(interface, &ld_usb_class);
         --> usb_minors[intf->minor] = NULL; [t2]
T1:
usb_open
   --> new_fops = fops_get(usb_minors[iminor(inode)]); [t1]
   --> err = file->f_op->open(inode, file);
       --> ...
       --> ld_usb_open
             --> dev = usb_get_intfdata(interface); [t3]

In T0, the interface is nullified before its get deregistered. Thus,
it is possible for T1 to still get the usb dev and access it via the
interface, which, however, has already been nullified.
The concurrent buggy order is t0 -> t1 -> t2 -> t3.

Thank you for your time and consideration.

Sincerely,
Ginger

Re: [bug report] Potential order bug in 'drivers/usb/misc/ldusb.c', mainly in 'ld_usb_disconnect()'

[Greg KH]

On Mon, Jun 01, 2026 at 12:10:37PM +0800, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential order bug within
> the 'drivers/usb/misc' subsystem, more specifically, in
> 'drivers/usb/misc/ldusb.c'.
> 
> This potential issue is similar to a previously reported one
> (https://lore.kernel.org/linux-usb/2026042444-freeing-consumer-468b@gregkh/).
> It is present as of git commit eb3f4b7426cfd2b79d65b7d37155480b32259a11.
> 
> Potential concurrent triggering executions:
> T0:
> ld_usb_disconnect
>     --> usb_set_intfdata(interface, NULL); [t0]
>     --> usb_deregister_dev(interface, &ld_usb_class);
>          --> usb_minors[intf->minor] = NULL; [t2]
> T1:
> usb_open
>    --> new_fops = fops_get(usb_minors[iminor(inode)]); [t1]
>    --> err = file->f_op->open(inode, file);
>        --> ...
>        --> ld_usb_open
>              --> dev = usb_get_intfdata(interface); [t3]
> 
> In T0, the interface is nullified before its get deregistered. Thus,
> it is possible for T1 to still get the usb dev and access it via the
> interface, which, however, has already been nullified.
> The concurrent buggy order is t0 -> t1 -> t2 -> t3.
> 
> Thank you for your time and consideration.

If you think this needs to be fixed, please just send a patch for it and
we can evaluate it that way.

thanks,

greg k-h