usb_serial_probe() initializes each port device with
device_initialize() before registering it with device_add().

If device_add() fails, the current code only logs an error and
continues, but does not drop the reference acquired by
device_initialize(). This leaves the failed port device referenced
until a later teardown path, if any.

Fix it by calling put_device() when device_add() fails. Also clear
serial->port[i] after put_device() so destroy_serial() will not try
to put the same device again.

Fixes: 41bd34ddd7aa ("usb-serial: change referencing of port and serial structures")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/usb/serial/usb-serial.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index c78ff40b1e5f..78e3eaf2874b 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -1148,8 +1148,11 @@ static int usb_serial_probe(struct usb_interface *interface,
 		device_enable_async_suspend(&port->dev);
 
 		retval = device_add(&port->dev);
-		if (retval)
+		if (retval) {
 			dev_err(ddev, "Error registering port device, continuing\n");
+			put_device(&port->dev);
+			serial->port[i] = NULL;
+		}
 	}
 
 	if (num_ports > 0)
-- 
2.43.0

On Mon, Apr 13, 2026 at 12:53:11AM +0800, Guangshuo Li wrote:
> usb_serial_probe() initializes each port device with
> device_initialize() before registering it with device_add().
> 
> If device_add() fails, the current code only logs an error and
> continues, but does not drop the reference acquired by
> device_initialize(). This leaves the failed port device referenced
> until a later teardown path, if any.
> 
> Fix it by calling put_device() when device_add() fails. Also clear
> serial->port[i] after put_device() so destroy_serial() will not try
> to put the same device again.

Any port that fails to register is released in destroy_serial() which is
called when the last reference to the device is dropped (e.g. when the
device is disconnected).

So there is nothing to fix here.

Are you using some kind of tool to find these "issues"?

Johan

Hi Johan,

Thanks, you are right.

I had missed the disconnect path: usb_serial_disconnect() retrieves the
serial object from usb_get_intfdata(interface) and then calls
usb_serial_put(serial), which can eventually release the ports through
destroy_serial().

So this is deferred cleanup rather than a refcount leak.

This report came from a static analysis result produced by a tool I am
developing, and my review of the report here was incomplete.

Please disregard this patch.

Best regards,
Guangshuo

Johan Hovold <johan@kernel.org> 于2026年4月13日周一 14:57写道：
>
> On Mon, Apr 13, 2026 at 12:53:11AM +0800, Guangshuo Li wrote:
> > usb_serial_probe() initializes each port device with
> > device_initialize() before registering it with device_add().
> >
> > If device_add() fails, the current code only logs an error and
> > continues, but does not drop the reference acquired by
> > device_initialize(). This leaves the failed port device referenced
> > until a later teardown path, if any.
> >
> > Fix it by calling put_device() when device_add() fails. Also clear
> > serial->port[i] after put_device() so destroy_serial() will not try
> > to put the same device again.
>
> Any port that fails to register is released in destroy_serial() which is
> called when the last reference to the device is dropped (e.g. when the
> device is disconnected).
>
> So there is nothing to fix here.
>
> Are you using some kind of tool to find these "issues"?
>
> Johan

Hi Guangshuo,

[ Remember to avoid top-posting when posting to the lists. ]

On Mon, Apr 13, 2026 at 03:55:09PM +0800, Guangshuo Li wrote:

> This report came from a static analysis result produced by a tool I am
> developing, and my review of the report here was incomplete.

Please mention that in the commit messages.

Johan

Johan Hovold <johan@kernel.org> 于2026年4月13日周一 16:10写道：

> Please mention that in the commit messages.

Hi Johan,

Understood, thanks. I will mention that in the commit messages for
future reports found by my static analysis tool.

Best regards,
Guangshuo