From: Michal Pecio <michal.pecio@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Xu Rao <raoxu@uniontech.com>,
mathias.nyman@linux.intel.com, niklas.neronin@linux.intel.com,
stern@rowland.harvard.edu, ukaszb@chromium.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xhci: sideband: fix ring sg table pages leak
Date: Sat, 11 Jul 2026 12:05:25 +0200 [thread overview]
Message-ID: <20260711120525.0afec034.michal.pecio@gmail.com> (raw)
In-Reply-To: <2026071028-sacrament-paradox-ea01@gregkh>
On Fri, 10 Jul 2026 15:51:17 +0200, Greg KH wrote:
> On Tue, Jun 02, 2026 at 11:43:27AM +0800, Xu Rao wrote:
> > xhci_ring_to_sgtable() allocates a temporary pages array and
> > uses it to build the returned sg_table with
> > sg_alloc_table_from_pages().
> >
> > The error paths free the pages array, but the success path
> > returns the sg_table without freeing it. This leaks the temporary
> > array every time a sideband client gets an endpoint or event ring
> > buffer.
> >
> > Free the pages array after sg_alloc_table_from_pages() succeeds.
> > The returned sg_table has its own scatterlist entries and does not
> > depend on the temporary array after construction.
> >
> > Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
> >
> > Signed-off-by: Xu Rao <raoxu@uniontech.com>
> > ---
> > drivers/usb/host/xhci-sideband.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> > index 23153e136d4b..a5deeee4d5dc 100644
> > --- a/drivers/usb/host/xhci-sideband.c
> > +++ b/drivers/usb/host/xhci-sideband.c
> > @@ -58,6 +58,8 @@ xhci_ring_to_sgtable(struct xhci_sideband *sb, struct xhci_ring *ring)
> > if (sg_alloc_table_from_pages(sgt, pages, n_pages, 0, sz, GFP_KERNEL))
> > goto err;
> >
> > + kvfree(pages);
>
> This looks very odd, how was this tested? If
> sg_alloc_table_from_pages() succeeds, then the table has the pages in
> it, you don't want to free them again, right?
This functions copies pointers to long-lived allocations from private
driver data structures into a standard sg_table.
'pages' is an array temporarily holding references to ring segments,
under the optimistic assumption that segments are exactly page sized.
If they aren't, the returned sg_table is wrong, and if page size > 4K
then 'pages' is allocated too short and used out of bounds.
AFAIU, sg_alloc_table_from_pages() converts those page pointers into
addresses stored in scatterlist nodes, so freeing 'pages' is right.
But see above, the whole implementation is questionable.
> And if this is such a major bug, why hasn't anyone noticed the leak
> yet?
The leak is a few bytes per offloaded device.
prev parent reply other threads:[~2026-07-11 10:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 3:43 [PATCH] xhci: sideband: fix ring sg table pages leak Xu Rao
2026-07-10 13:51 ` Greg KH
2026-07-11 10:05 ` Michal Pecio [this message]
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=20260711120525.0afec034.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@linux.intel.com \
--cc=raoxu@uniontech.com \
--cc=stern@rowland.harvard.edu \
--cc=ukaszb@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.