[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

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

[Ginger]

Thank you for the prompt response. The patch draft is attached below.
Would it be enough to send the patch to you, or should I draft it into
a different email?

Thanks.

Best regards,
Ginger

----------------------------------------------------------------------------


[PATCH] usb: misc: yurex: fix ordering of usb_deregister_dev() and
 usb_set_intfdata()

In yurex_disconnect(), usb_set_intfdata(interface, NULL) was called
before usb_deregister_dev(interface, &yurex_class).  This opens a race
window with usb_open() in the USB core:

  T0 (yurex_disconnect)               T1 (usb_open)
  --------------------------           -------------------------
  usb_set_intfdata(iface, NULL) [t0]
                                       fops = usb_minors[minor]  [t1]
                                       /* fops still valid here */
  usb_deregister_dev()
    usb_minors[minor] = NULL   [t2]
                                       file->f_op->open(inode, file)
                                         yurex_open()
                                           dev = usb_get_intfdata() [t3]
                                           /* dev is NULL! */

Fix the race by calling usb_deregister_dev() first, which removes the
device from usb_minors[] before the interface data pointer is cleared.

Reported-by: Ginger <ginger.jzllee@gmail.com>
---
 drivers/usb/misc/yurex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index 6d03e689850a..b5484ab77e91 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -310,11 +310,12 @@ static void yurex_disconnect(struct
usb_interface *interface)
    int minor = interface->minor;

    dev = usb_get_intfdata(interface);
-   usb_set_intfdata(interface, NULL);

    /* give back our minor */
    usb_deregister_dev(interface, &yurex_class);

+   usb_set_intfdata(interface, NULL);
+
    /* prevent more I/O from starting */
    usb_poison_urb(dev->urb);
    usb_poison_urb(dev->cntl_urb);
---

On Fri, Apr 24, 2026 at 11:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> 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

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

[Greg KH]

On Mon, Apr 27, 2026 at 11:36:39AM +0800, Ginger wrote:
> Thank you for the prompt response. The patch draft is attached below.
> Would it be enough to send the patch to you, or should I draft it into
> a different email?

Please just follow the normally documented process for submitting a
patch and we can take it from there.

thanks,

greg k-h