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

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

[Ginger]

Dear Linux kernel maintainers,

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

Kernel version: long-term kernel v6.18.9

Potential concurrent triggering executions:
T0:
yurex_disconnect
    --> usb_set_intfdata(interface, NULL); [t0]
    --> usb_deregister_dev(interface, &yurex_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);
       --> ...
       --> yurex_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 been already 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/yurex.c', mainly in 'yurex_disconnect()'

[Greg KH]

On Fri, Apr 24, 2026 at 11:01:04PM +0800, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential orderbug within
> the 'drivers/usb/misc' subsystem, more specifically, in
> 'drivers/usb/misc/yurex.c'.
> 
> Kernel version: long-term kernel v6.18.9
> 
> Potential concurrent triggering executions:
> T0:
> yurex_disconnect
>     --> usb_set_intfdata(interface, NULL); [t0]
>     --> usb_deregister_dev(interface, &yurex_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);
>        --> ...
>        --> yurex_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 been already nullified.
> The concurrent buggy order is t0 -> t1 -> t2 -> t3.

Great, can you send a patch to fix this?

thanks,

greg k-h