From: Michal Pecio <michal.pecio@gmail.com>
To: Zilin Guan <zilin@seu.edu.cn>
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
jianhao.xu@seu.edu.cn, stable@vger.kernel.org
Subject: Re: [PATCH v3] usb: xhci: Fix memory leak in xhci_disable_slot()
Date: Thu, 29 Jan 2026 09:56:34 +0100 [thread overview]
Message-ID: <20260129095634.0775dc40.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260109045410.1532614-1-zilin@seu.edu.cn>
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@vger.kernel.org
> Signed-off-by: Zilin Guan <zilin@seu.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
next prev parent reply other threads:[~2026-01-29 8:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 4:54 [PATCH v3] usb: xhci: Fix memory leak in xhci_disable_slot() Zilin Guan
2026-01-29 8:56 ` Michal Pecio [this message]
2026-01-29 11:38 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260129095634.0775dc40.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jianhao.xu@seu.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=stable@vger.kernel.org \
--cc=zilin@seu.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox