[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260129095634.0775dc40.michal.pecio@gmail.com>
Date: Thu, 29 Jan 2026 09:56:34 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Zilin Guan <zilin@....edu.cn>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
jianhao.xu@....edu.cn, stable@...r.kernel.org
Subject: Re: [PATCH v3] usb: xhci: Fix memory leak in xhci_disable_slot()
On Fri, 9 Jan 2026 04:54:10 +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.
>
> Use xhci_free_command() instead of kfree(). xhci_free_command()
> correctly frees both the command structure and the associated
> completion structure. Since the command structure is allocated with
> zero-initialization, command->in_ctx is NULL and will not be
> erroneously freed by xhci_free_command().
>
> This bug was found using an experimental static analysis tool we are
> developing. The tool is based on the LLVM framework and is
> specifically designed to detect memory management issues. It is
> currently under active development and not yet publicly available,
> but we plan to open-source it after our research is published.
>
> The bug was originally detected on v6.13-rc1 using our static analysis
> tool, and we have verified that the issue persists in the latest
> mainline kernel.
>
> We performed build testing on x86_64 with allyesconfig using
> GCC=11.4.0. Since triggering these error paths 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 paths at runtime.
>
> Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command
> and host runtime suspend") CC: stable@...r.kernel.org
> Signed-off-by: Zilin Guan <zilin@....edu.cn>
This looks like correct fix to an actual bug, but it seems that it has
been missed? I see it neither in usb-next nor usb-linus or mainline.
The leak is still there, even if arguably a small and rare one.
Regards,
Michal
Powered by blists - more mailing lists