[PATCH] usb: gadget: goku_udc: fix kobject warning on probe failure

[PATCH] usb: gadget: goku_udc: fix kobject warning on probe failure

[Cheng Lingfei]

goku_probe() calls goku_remove() when hardware initialization fails, but
the gadget device is initialized only near the end of probe. As a result,
goku_remove() calls usb_del_gadget_udc(), which drops a reference to an
uninitialized gadget device and triggers a kobject warning.

Initialize the gadget device immediately after allocating the controller,
but add it only after all hardware resources have been acquired. Track the
gadget and proc entry registration state so goku_remove() can safely clean
up both partial probe state and a fully initialized device.

Use the split gadget removal API and drop the final gadget reference only
after all hardware resources have been released.

Also obtain the controller from the embedded gadget device in the release
callback. Driver data is set on the PCI device rather than the gadget
device, so using dev_get_drvdata() there fails to free the controller.

Use a per-device name for the debug proc entry so that multiple
controllers can be registered without colliding on /proc/driver/udc.

Fixes: 3301c215a2bb ("USB: UDC: Expand device model API interface")
Reported-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=06ec7624018233e17113
Tested-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com

Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com>
---
 drivers/usb/gadget/udc/goku_udc.c | 40 +++++++++++++++++++++------------------
 drivers/usb/gadget/udc/goku_udc.h |  8 ++++++--
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c
index ac2a984c2f87..7af6da63e83b 100644
--- a/drivers/usb/gadget/udc/goku_udc.c
+++ b/drivers/usb/gadget/udc/goku_udc.c
@@ -20,6 +20,7 @@
 // #define	VERBOSE		/* extra debug messages (success too) */
 // #define	USB_TRACE	/* packet-level success messages */
 
+#include <linux/container_of.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/pci.h>
@@ -1052,8 +1053,6 @@ static inline const char *dmastr(void)
 
 #ifdef CONFIG_USB_GADGET_DEBUG_FILES
 
-static const char proc_node_name [] = "driver/udc";
-
 #define FOURBITS "%s%s%s%s"
 #define EIGHTBITS FOURBITS FOURBITS
 
@@ -1701,7 +1700,7 @@ static irqreturn_t goku_irq(int irq, void *_dev)
 
 static void gadget_release(struct device *_dev)
 {
-	struct goku_udc	*dev = dev_get_drvdata(_dev);
+	struct goku_udc *dev = container_of(_dev, struct goku_udc, gadget.dev);
 
 	kfree(dev);
 }
@@ -1714,12 +1713,13 @@ static void goku_remove(struct pci_dev *pdev)
 
 	DBG(dev, "%s\n", __func__);
 
-	usb_del_gadget_udc(&dev->gadget);
+	if (dev->added)
+		usb_del_gadget(&dev->gadget);
 
 	BUG_ON(dev->driver);
 
 #ifdef CONFIG_USB_GADGET_DEBUG_FILES
-	remove_proc_entry(proc_node_name, NULL);
+	proc_remove(dev->proc_entry);
 #endif
 	if (dev->regs)
 		udc_reset(dev);
@@ -1736,6 +1736,8 @@ static void goku_remove(struct pci_dev *pdev)
 	dev->regs = NULL;
 
 	INFO(dev, "unbind\n");
+
+	usb_put_gadget(&dev->gadget);
 }
 
 /* wrap this driver around the specified pci device, but
@@ -1748,19 +1750,19 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	unsigned long		resource, len;
 	void __iomem		*base = NULL;
 	int			retval;
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+	char			proc_node_name[64];
+#endif
 
 	if (!pdev->irq) {
 		printk(KERN_ERR "Check PCI %s IRQ setup!\n", pci_name(pdev));
-		retval = -ENODEV;
-		goto err;
+		return -ENODEV;
 	}
 
 	/* alloc, and start init */
 	dev = kzalloc_obj(*dev);
-	if (!dev) {
-		retval = -ENOMEM;
-		goto err;
-	}
+	if (!dev)
+		return -ENOMEM;
 
 	pci_set_drvdata(pdev, dev);
 	spin_lock_init(&dev->lock);
@@ -1771,6 +1773,8 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	/* the "gadget" abstracts/virtualizes the controller */
 	dev->gadget.name = driver_name;
 
+	usb_initialize_gadget(&pdev->dev, &dev->gadget, gadget_release);
+
 	/* now all the pci goodies ... */
 	retval = pci_enable_device(pdev);
 	if (retval < 0) {
@@ -1815,21 +1819,21 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 
 
 #ifdef CONFIG_USB_GADGET_DEBUG_FILES
-	proc_create_single_data(proc_node_name, 0, NULL, udc_proc_read, dev);
+	snprintf(proc_node_name, sizeof(proc_node_name), "driver/goku_udc-%s",
+		 pci_name(pdev));
+	dev->proc_entry = proc_create_single_data(proc_node_name, 0, NULL,
+						  udc_proc_read, dev);
 #endif
 
-	retval = usb_add_gadget_udc_release(&pdev->dev, &dev->gadget,
-			gadget_release);
+	retval = usb_add_gadget(&dev->gadget);
 	if (retval)
 		goto err;
+	dev->added = 1;
 
 	return 0;
 
 err:
-	if (dev)
-		goku_remove (pdev);
-	/* gadget_release is not registered yet, kfree explicitly */
-	kfree(dev);
+	goku_remove(pdev);
 	return retval;
 }
 
diff --git a/drivers/usb/gadget/udc/goku_udc.h b/drivers/usb/gadget/udc/goku_udc.h
index 70023d401079..0ca2d49d25ba 100644
--- a/drivers/usb/gadget/udc/goku_udc.h
+++ b/drivers/usb/gadget/udc/goku_udc.h
@@ -247,7 +247,12 @@ struct goku_udc {
 					got_region:1,
 					req_config:1,
 					configured:1,
-					enabled:1;
+					enabled:1,
+					added:1;
+
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+	struct proc_dir_entry		*proc_entry;
+#endif
 
 	/* pci state used to access those endpoints */
 	struct pci_dev			*pdev;
@@ -286,4 +291,3 @@ struct goku_udc {
 	xprintk(dev , KERN_WARNING , fmt , ## args)
 #define INFO(dev,fmt,args...) \
 	xprintk(dev , KERN_INFO , fmt , ## args)
-

---
base-commit: 3aa1dcaa4f6f5ae08936491e08bd456f331f2d40
change-id: 20260826-b4-fix-usb-c1a4f0505d8c

Best regards,
--  
Cheng Lingfei <chenglingfei@foxmail.com>

Re: [PATCH] usb: gadget: goku_udc: fix kobject warning on probe failure

[Greg Kroah-Hartman]

On Wed, Aug 26, 2026 at 11:35:58AM +0800, Cheng Lingfei wrote:
> goku_probe() calls goku_remove() when hardware initialization fails, but
> the gadget device is initialized only near the end of probe. As a result,
> goku_remove() calls usb_del_gadget_udc(), which drops a reference to an
> uninitialized gadget device and triggers a kobject warning.
> 
> Initialize the gadget device immediately after allocating the controller,
> but add it only after all hardware resources have been acquired. Track the
> gadget and proc entry registration state so goku_remove() can safely clean
> up both partial probe state and a fully initialized device.
> 
> Use the split gadget removal API and drop the final gadget reference only
> after all hardware resources have been released.
> 
> Also obtain the controller from the embedded gadget device in the release
> callback. Driver data is set on the PCI device rather than the gadget
> device, so using dev_get_drvdata() there fails to free the controller.
> 
> Use a per-device name for the debug proc entry so that multiple
> controllers can be registered without colliding on /proc/driver/udc.
> 
> Fixes: 3301c215a2bb ("USB: UDC: Expand device model API interface")
> Reported-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=06ec7624018233e17113
> Tested-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
> 
> Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com>

No Assisted-by: line?

And do you see this happening in a real device and not just a fake one?

And why is this driver using proc at all, shouldn't that be in debugfs
instead?

thanks,

greg k-h

Re: [PATCH] usb: gadget: goku_udc: fix kobject warning on probe failure

[Cheng Lingfei]

On 8/26/2026 2:11 PM, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2026 at 11:35:58AM +0800, Cheng Lingfei wrote:
>> goku_probe() calls goku_remove() when hardware initialization fails, but
>> the gadget device is initialized only near the end of probe. As a result,
>> goku_remove() calls usb_del_gadget_udc(), which drops a reference to an
>> uninitialized gadget device and triggers a kobject warning.
>>
>> Initialize the gadget device immediately after allocating the controller,
>> but add it only after all hardware resources have been acquired. Track the
>> gadget and proc entry registration state so goku_remove() can safely clean
>> up both partial probe state and a fully initialized device.
>>
>> Use the split gadget removal API and drop the final gadget reference only
>> after all hardware resources have been released.
>>
>> Also obtain the controller from the embedded gadget device in the release
>> callback. Driver data is set on the PCI device rather than the gadget
>> device, so using dev_get_drvdata() there fails to free the controller.
>>
>> Use a per-device name for the debug proc entry so that multiple
>> controllers can be registered without colliding on /proc/driver/udc.
>>
>> Fixes: 3301c215a2bb ("USB: UDC: Expand device model API interface")
>> Reported-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=06ec7624018233e17113
>> Tested-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
>>
>> Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com>
> 
> No Assisted-by: line?
> 
> And do you see this happening in a real device and not just a fake one?
> 
> And why is this driver using proc at all, shouldn't that be in debugfs
> instead?
> 
> thanks,
> 
> greg k-h

Thanks for the review.

I do not have TC86C001 hardware. The issue was reproduced only by
syzbot, whose reproducer binds goku_udc to unrelated QEMU PCI devices
through the PCI new_id interface.

The probe cleanup path itself can also be reached on real hardware if
one of the probe steps fails, but I cannot claim that the issue has
been reproduced on real hardware.

The proc entry is legacy diagnostic code from this old driver, so I
agree that debugfs is the appropriate interface. I will rework the
patch accordingly and send a v2.

I will also add the missing Assisted-by line.

Re: [PATCH] usb: gadget: goku_udc: fix kobject warning on probe failure

[Greg Kroah-Hartman]

On Wed, Aug 26, 2026 at 03:00:37PM +0800, Cheng Lingfei wrote:
> On 8/26/2026 2:11 PM, Greg Kroah-Hartman wrote:
> > On Wed, Aug 26, 2026 at 11:35:58AM +0800, Cheng Lingfei wrote:
> > > goku_probe() calls goku_remove() when hardware initialization fails, but
> > > the gadget device is initialized only near the end of probe. As a result,
> > > goku_remove() calls usb_del_gadget_udc(), which drops a reference to an
> > > uninitialized gadget device and triggers a kobject warning.
> > > 
> > > Initialize the gadget device immediately after allocating the controller,
> > > but add it only after all hardware resources have been acquired. Track the
> > > gadget and proc entry registration state so goku_remove() can safely clean
> > > up both partial probe state and a fully initialized device.
> > > 
> > > Use the split gadget removal API and drop the final gadget reference only
> > > after all hardware resources have been released.
> > > 
> > > Also obtain the controller from the embedded gadget device in the release
> > > callback. Driver data is set on the PCI device rather than the gadget
> > > device, so using dev_get_drvdata() there fails to free the controller.
> > > 
> > > Use a per-device name for the debug proc entry so that multiple
> > > controllers can be registered without colliding on /proc/driver/udc.
> > > 
> > > Fixes: 3301c215a2bb ("USB: UDC: Expand device model API interface")
> > > Reported-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=06ec7624018233e17113
> > > Tested-by: syzbot+06ec7624018233e17113@syzkaller.appspotmail.com
> > > 
> > > Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com>
> > 
> > No Assisted-by: line?
> > 
> > And do you see this happening in a real device and not just a fake one?
> > 
> > And why is this driver using proc at all, shouldn't that be in debugfs
> > instead?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Thanks for the review.
> 
> I do not have TC86C001 hardware. The issue was reproduced only by
> syzbot, whose reproducer binds goku_udc to unrelated QEMU PCI devices
> through the PCI new_id interface.

Which is an invalid operation, you don't have to worry about that ever
happening in a real world situation.  syzbot is wrong here.

> The probe cleanup path itself can also be reached on real hardware if
> one of the probe steps fails, but I cannot claim that the issue has
> been reproduced on real hardware.
> 
> The proc entry is legacy diagnostic code from this old driver, so I
> agree that debugfs is the appropriate interface. I will rework the
> patch accordingly and send a v2.
> 
> I will also add the missing Assisted-by line.

thanks!

greg k-h