Re: [PATCH v2] usb: usbtest: disable dynamic ID support

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Aug 06, 2026 at 04:35:12PM +0200, Aleksandr Nogikh wrote:
> On Thu, Aug 6, 2026 at 4:32 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Aug 06, 2026 at 02:25:11PM +0000, Aleksandr Nogikh wrote:
> > > The usbtest driver relies on the driver_info field of struct usb_device_id
> > > to point to a valid struct usbtest_info descriptor. This structure contains
> > > essential test configurations, such as endpoint addresses and test modes,
> > > which are required during probe.
> > >
> > > When a user dynamically adds a new device ID via the sysfs new_id
> > > interface without specifying a reference device, the USB core initializes
> > > driver_info to 0 (NULL). When a matching device is subsequently probed,
> > > usbtest_probe() unconditionally casts driver_info to a struct usbtest_info
> > > pointer and dereferences it, leading to a NULL pointer dereference crash:
> > >
> > >   Oops: general protection fault, probably for non-canonical address
> > >   0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
> > >   KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > >   RIP: 0010:usbtest_probe+0x3b9/0x1280 drivers/usb/misc/usbtest.c:2822
> > >
> > > Because usbtest strictly requires pre-defined usbtest_info descriptors
> > > to function, dynamic ID binding via sysfs is fundamentally unsupported
> > > for this driver.
> > >
> > > Fix this by setting .no_dynamic_id = 1 on usbtest_driver. This instructs
> > > the USB core to skip creating the new_id and remove_id sysfs interfaces
> > > for usbtest, preventing invalid dynamic ID entries from being created.
> > >
> > > Reported-by: syzbot+7e1e5911f9eac50bedc7@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=7e1e5911f9eac50bedc7
> > > Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
> >
> > Shouldn't this also get a cc: stable?
> 
> Is there (in general) value in cc: stable without a Fixes: tag?

Very much so.  Don't you want this in stable trees so that your syzbot
runs on the older kernels don't fail horribly?  If not, then hey,
waiting for newer releases is fine with me, but I got the impression
this was a good thing to fix :)

thanks,

greg k-h