xhci_alloc_command() allocates a command structure and, when the
second argument is true, also allocates a completion structure.
Currently, the error handling path in xhci_disable_slot() only frees
the command structure using kfree(), causing the completion structure
to leak.

Fix this by using xhci_free_command() instead of kfree(). This function
correctly frees both the command and the completion structure.

Fixes: cd3f1790b006d ("usb: xhci: Fix potential memory leak in xhci_disable_slot()")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
 drivers/usb/host/xhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 02c9bfe21ae2..f0beed054954 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4137,7 +4137,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
 	if (state == 0xffffffff || (xhci->xhc_state & XHCI_STATE_DYING) ||
 			(xhci->xhc_state & XHCI_STATE_HALTED)) {
 		spin_unlock_irqrestore(&xhci->lock, flags);
-		kfree(command);
+		xhci_free_command(xhci, command);
 		return -ENODEV;
 	}
 
@@ -4145,7 +4145,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
 				slot_id);
 	if (ret) {
 		spin_unlock_irqrestore(&xhci->lock, flags);
-		kfree(command);
+		xhci_free_command(xhci, command);
 		return ret;
 	}
 	xhci_ring_cmd_db(xhci);
-- 
2.34.1

On Thu, Dec 25, 2025 at 04:21:19PM +0000, Zilin Guan wrote:
> xhci_alloc_command() allocates a command structure and, when the
> second argument is true, also allocates a completion structure.
> Currently, the error handling path in xhci_disable_slot() only frees
> the command structure using kfree(), causing the completion structure
> to leak.
> 
> Fix this by using xhci_free_command() instead of kfree(). This function
> correctly frees both the command and the completion structure.
> 
> Fixes: cd3f1790b006d ("usb: xhci: Fix potential memory leak in xhci_disable_slot()")

No cc: stable?

And how was this found?  How was it tested?  What tool created this fix?

thanks,

greg k-h

On Wed, Jan 07, 2026 at 04:04:43PM +0100, Greg KH wrote:
> On Thu, Dec 25, 2025 at 04:21:19PM +0000, Zilin Guan wrote:
> > xhci_alloc_command() allocates a command structure and, when the
> > second argument is true, also allocates a completion structure.
> > Currently, the error handling path in xhci_disable_slot() only frees
> > the command structure using kfree(), causing the completion structure
> > to leak.
> > 
> > Fix this by using xhci_free_command() instead of kfree(). This function
> > correctly frees both the command and the completion structure.
> > 
> > Fixes: cd3f1790b006d ("usb: xhci: Fix potential memory leak in xhci_disable_slot()")
> 
> No cc: stable?

My understanding is that the Cc: stable tag is primarily intended for 
severe bugs. I wasn't sure if this leak was critical enough to warrant 
backporting, especially since the amount of leaked memory is small. I 
decided to avoid adding unnecessary noise to the stable tree, but I am 
happy to include the tag if you advise doing so.

> And how was this found?  How was it tested?  

This issue was reported by our static analysis tool, but we manually verify 
the bugs.

We enforced a rigorous manual check to trace the code path and confirm 
the resource leak is genuine specifically to filter out any false 
positives from the tool.

> What tool created this fix?

We wrote patch manually.

Thanks,
Zilin Guan

On Thu, Jan 08, 2026 at 02:37:10AM +0000, Zilin Guan wrote:
> On Wed, Jan 07, 2026 at 04:04:43PM +0100, Greg KH wrote:
> > On Thu, Dec 25, 2025 at 04:21:19PM +0000, Zilin Guan wrote:
> > > xhci_alloc_command() allocates a command structure and, when the
> > > second argument is true, also allocates a completion structure.
> > > Currently, the error handling path in xhci_disable_slot() only frees
> > > the command structure using kfree(), causing the completion structure
> > > to leak.
> > > 
> > > Fix this by using xhci_free_command() instead of kfree(). This function
> > > correctly frees both the command and the completion structure.
> > > 
> > > Fixes: cd3f1790b006d ("usb: xhci: Fix potential memory leak in xhci_disable_slot()")
> > 
> > No cc: stable?
> 
> My understanding is that the Cc: stable tag is primarily intended for 
> severe bugs. I wasn't sure if this leak was critical enough to warrant 
> backporting, especially since the amount of leaked memory is small. I 
> decided to avoid adding unnecessary noise to the stable tree, but I am 
> happy to include the tag if you advise doing so.
> 
> > And how was this found?  How was it tested?  
> 
> This issue was reported by our static analysis tool, but we manually verify 
> the bugs.

As per our documentation, you need to describe the tool being used,
please read and follow that, otherwise we have no idea of what is
happening here.

thanks,

greg k-h

On Thu, Jan 08, 2026 at 06:42:51AM +0100, Greg KH wrote:
> As per our documentation, you need to describe the tool being used,
> please read and follow that, otherwise we have no idea of what is
> happening here.
> 
> thanks,
> 
> greg k-h

The tool used is an experimental static analysis tool we are developing. 
It is based on the LLVM framework and specifically designed to detect 
memory management issues.

The tool is currently under active development, so we do not have a public 
repository link at this moment. However, we plan to open-source it once 
the associated research is published.

We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. 
Since triggering these error path in xhci_disable_slot() requires specific 
hardware conditions or abnormal state, we were unable to construct a test 
case to reliably trigger these specific error path at runtime.

I will send a v2 patch with the tool description included in the commit
message, and I'll further clarify why the proposed fix is safe. Do you
think there's anything else to add?

Thanks,
Zilin Guan

On Thu, Jan 08, 2026 at 09:05:31AM +0000, Zilin Guan wrote:
> On Thu, Jan 08, 2026 at 06:42:51AM +0100, Greg KH wrote:
> > As per our documentation, you need to describe the tool being used,
> > please read and follow that, otherwise we have no idea of what is
> > happening here.
> > 
> > thanks,
> > 
> > greg k-h
> 
> The tool used is an experimental static analysis tool we are developing. 
> It is based on the LLVM framework and specifically designed to detect 
> memory management issues.
> 
> The tool is currently under active development, so we do not have a public 
> repository link at this moment. However, we plan to open-source it once 
> the associated research is published.

As per our documentation, you need to say all of this.  Please read:
	Documentation/process/researcher-guidelines.rst
and follow that.

thanks,

greg k-h

On Thu, Jan 08, 2026 at 10:15:21AM +0100, Greg KH wrote:
> > The tool used is an experimental static analysis tool we are developing. 
> > It is based on the LLVM framework and specifically designed to detect 
> > memory management issues.
> > 
> > The tool is currently under active development, so we do not have a public 
> > repository link at this moment. However, we plan to open-source it once 
> > the associated research is published.
> 
> As per our documentation, you need to say all of this.  Please read:
> 	Documentation/process/researcher-guidelines.rst
> and follow that.
> 
> thanks,
> 
> greg k-h

Understood. I will include these details in v2 as per documentation.

Thanks,
Zilin Guan