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

[Greg KH <gregkh@linuxfoundation.org>]

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