[PATCH] usb: gadget: net2280: fix NULL pointer deref in usb_reinit_338x()

[PATCH] usb: gadget: net2280: fix NULL pointer deref in usb_reinit_338x()

[Deepanshu Kartikey]

net2280_probe() only maps dev->llregs when the PLX_PCIE quirk bit is
set. usb_reinit() dispatches to usb_reinit_338x() for any device that
doesn't have PLX_LEGACY set, assuming such a device must have
PLX_PCIE set (and thus llregs mapped). That assumption holds for
every entry in the driver's pci_device_id table, but a forced driver
bind (e.g. via sysfs bind/driver_override) can invoke probe() with
quirks that have neither bit set, leaving llregs NULL and crashing
in usb_reinit_338x() on the first readl().

Reject probe() early when quirks has neither PLX_LEGACY nor
PLX_PCIE set, instead of proceeding into a reinit path that assumes
one of them is always present.

Fixes: adc82f77bee3 ("usb: gadget: net2280: Add support for PLX USB338X")
Reported-by: syzbot+2ec7fc1793a63864d9d6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2ec7fc1793a63864d9d6
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 drivers/usb/gadget/udc/net2280.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 7c5f30cfd24d..02d12c2ad58b 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -3708,6 +3708,17 @@ static int net2280_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 		writel(0, &dev->usb->usbctl);
 	}
 
+	/* usb_reinit() dispatches on PLX_LEGACY vs PLX_PCIE and assumes
+	 * every non-legacy chip has llregs mapped (PLX_PCIE branch above).
+	 * A forced/mismatched driver bind can hand us quirks that satisfy
+	 * neither, so refuse to proceed rather than dereference NULL.
+	 */
+	if (!(dev->quirks & (PLX_LEGACY | PLX_PCIE))) {
+		ep_err(dev, "unsupported device (quirks=%#lx)\n", dev->quirks);
+		retval = -ENODEV;
+		goto done;
+	}
+
 	usb_reset(dev);
 	usb_reinit(dev);
 
-- 
2.43.0

Re: [PATCH] usb: gadget: net2280: fix NULL pointer deref in usb_reinit_338x()

[Alan Stern]

On Fri, Aug 21, 2026 at 05:42:20PM +0530, Deepanshu Kartikey wrote:
> net2280_probe() only maps dev->llregs when the PLX_PCIE quirk bit is
> set. usb_reinit() dispatches to usb_reinit_338x() for any device that
> doesn't have PLX_LEGACY set, assuming such a device must have
> PLX_PCIE set (and thus llregs mapped). That assumption holds for
> every entry in the driver's pci_device_id table, but a forced driver
> bind (e.g. via sysfs bind/driver_override) can invoke probe() with
> quirks that have neither bit set, leaving llregs NULL and crashing
> in usb_reinit_338x() on the first readl().
> 
> Reject probe() early when quirks has neither PLX_LEGACY nor
> PLX_PCIE set, instead of proceeding into a reinit path that assumes
> one of them is always present.
> 
> Fixes: adc82f77bee3 ("usb: gadget: net2280: Add support for PLX USB338X")
> Reported-by: syzbot+2ec7fc1793a63864d9d6@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2ec7fc1793a63864d9d6
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  drivers/usb/gadget/udc/net2280.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
> index 7c5f30cfd24d..02d12c2ad58b 100644
> --- a/drivers/usb/gadget/udc/net2280.c
> +++ b/drivers/usb/gadget/udc/net2280.c
> @@ -3708,6 +3708,17 @@ static int net2280_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  		writel(0, &dev->usb->usbctl);
>  	}
>  
> +	/* usb_reinit() dispatches on PLX_LEGACY vs PLX_PCIE and assumes
> +	 * every non-legacy chip has llregs mapped (PLX_PCIE branch above).
> +	 * A forced/mismatched driver bind can hand us quirks that satisfy
> +	 * neither, so refuse to proceed rather than dereference NULL.
> +	 */

This is a rather verbose comment (it sounds almost like it was written 
by an AI).  You could just say:

	/* If neither PLX_LEGACY nor PLX_PCIE is set, usb_reinit() will fail */

> +	if (!(dev->quirks & (PLX_LEGACY | PLX_PCIE))) {
> +		ep_err(dev, "unsupported device (quirks=%#lx)\n", dev->quirks);

People generally don't use the # modifier in kernel log messages.

> +		retval = -ENODEV;
> +		goto done;
> +	}
> +
>  	usb_reset(dev);
>  	usb_reinit(dev);
>  
> -- 
> 2.43.0
> 

Re: [PATCH] usb: gadget: net2280: fix NULL pointer deref in usb_reinit_338x()

[Greg KH]

On Fri, Aug 21, 2026 at 05:42:20PM +0530, Deepanshu Kartikey wrote:
> net2280_probe() only maps dev->llregs when the PLX_PCIE quirk bit is
> set. usb_reinit() dispatches to usb_reinit_338x() for any device that
> doesn't have PLX_LEGACY set, assuming such a device must have
> PLX_PCIE set (and thus llregs mapped). That assumption holds for
> every entry in the driver's pci_device_id table, but a forced driver
> bind (e.g. via sysfs bind/driver_override) can invoke probe() with
> quirks that have neither bit set, leaving llregs NULL and crashing
> in usb_reinit_338x() on the first readl().

What is it with the forced bind patches coming out of the woodwork?  Did
syzbot just decide to go crazy here?

Again, no, this isn't a real issue.  If you try to do a bind to a random
driver, you will get random results, including crashes.  This is a
debugging-only feature for people who want to break their kernels :)

thanks,

greg k-h

Re: [PATCH] usb: gadget: net2280: fix NULL pointer deref in usb_reinit_338x()

[Deepanshu Kartikey]

On Fri, Aug 21, 2026 at 8:37 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> What is it with the forced bind patches coming out of the woodwork?  Did
> syzbot just decide to go crazy here?
>
> Again, no, this isn't a real issue.  If you try to do a bind to a random
> driver, you will get random results, including crashes.  This is a
> debugging-only feature for people who want to break their kernels :)
>
> thanks,
>
> greg k-h

Understood, thanks for the context - I hadn't realized forced bind via
sysfs was considered out of scope for these kinds of fixes.

Alan also left some style feedback on the patch (trim the comment,
drop the # modifier in the log message) independent of whether the
patch itself is wanted. Before I send a v2 with those changes: do you
want this patch at all, given it's only reachable through the
debug-only forced-bind path? Happy to drop it entirely if not, or
send v2 with Alan's suggestions if it's still worth taking as a
defensive cleanup.

Thanks,
Deepanshu