[BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[co]

We found a bug reachable in:

    path    drivers/usb/host
    crash   out-of-bounds in xhci_queue_bulk_tx()
    commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")

Config, environment, the sanitizer report and a C reproducer follow.

== Notes ===============================================================
    If you patch the bug based on our artifacts, a tag would be
    appreciated:

Reported-by: co+fd80bc5967eb22c3@bugs.sh

    Everything in this mail is validated by the reproducer below.

    We also hold an LLM-generated root-cause analysis and a candidate
    patch. The patch passes an A/B test: the same reproducer panics the
    unpatched kernel and runs clean on the patched one. Neither has had
    human review, so both still require validation before you send or
    apply them. Available on:

        patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
        report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md

    This is an open science project. The code and the full set of PoCs
    are not public at this moment, as we intend to disclose our findings
    in an ethical way.

    Happy to test patches. Complaints and suggestions about our work
    are welcome at:

        cedalion@bugs.sh

== Environment =========================================================
    Reproduced on  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
    VM setup       https://bugs.sh/b/fd80bc5967eb22c3/run.sh
    config         https://bugs.sh/b/fd80bc5967eb22c3/config.gz
    poc            https://bugs.sh/b/fd80bc5967eb22c3/repro.c

== Sanitizer Report ====================================================
BUG: KASAN: slab-out-of-bounds in xhci_queue_bulk_tx (drivers/usb/host/xhci-ring.c:3564 (discriminator 6) drivers/usb/host/xhci-ring.c:3673 (discriminator 6))
Write of size 1024 at addr ffff88801489b400 by task exploit/146
CPU: 0 UID: 0 PID: 146 Comm: exploit Not tainted 7.2.0+ #9 PREEMPTLAZY
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200)
__asan_memcpy (mm/kasan/shadow.c:106 (discriminator 1))
xhci_queue_bulk_tx (drivers/usb/host/xhci-ring.c:3564 (discriminator 6) drivers/usb/host/xhci-ring.c:3673 (discriminator 6))
xhci_urb_enqueue (drivers/usb/host/xhci.c:1701)
usb_hcd_submit_urb (drivers/usb/core/hcd.c:1542)
proc_do_submiturb (drivers/usb/core/devio.c:1967)
usbdev_ioctl (drivers/usb/core/devio.c:2002 drivers/usb/core/devio.c:2702 drivers/usb/core/devio.c:2826)
__x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:597 fs/ioctl.c:583 fs/ioctl.c:583)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Allocated by task 75:
The buggy address belongs to the object at ffff88801489b400
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 0 bytes inside of
allocated 512-byte region [ffff88801489b400, ffff88801489b600)
The buggy address belongs to the physical page:
Memory state around the buggy address:
ffff88801489b500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88801489b580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88801489b600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88801489b680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88801489b700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc


---
The report format is based on syzbot bug report.

This report is generated by a bot. It may contain errors.
See https://github.com/n132/cedalion for more information.

For any issue with this report, reach out to cedalion@bugs.sh

If the report is already addressed, let us know by replying with:
#co fix: <commit hash>

If the report is a duplicate of another one, reply with:
#co dup: <lore link>

If you want to undo deduplication, reply with:
#co undup

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg Kroah-Hartman]

On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> We found a bug reachable in:
> 
>     path    drivers/usb/host
>     crash   out-of-bounds in xhci_queue_bulk_tx()
>     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> 
> Config, environment, the sanitizer report and a C reproducer follow.
> 
> == Notes ===============================================================
>     If you patch the bug based on our artifacts, a tag would be
>     appreciated:
> 
> Reported-by: co+fd80bc5967eb22c3@bugs.sh
> 
>     Everything in this mail is validated by the reproducer below.
> 
>     We also hold an LLM-generated root-cause analysis and a candidate
>     patch. The patch passes an A/B test: the same reproducer panics the
>     unpatched kernel and runs clean on the patched one. Neither has had
>     human review, so both still require validation before you send or
>     apply them. Available on:
> 
>         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
>         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md

Please validate and ensure that this is correct before sending this to
us.  No need for us to dig through random web links, right?

thanks,

greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Xiang Mei]

Th

On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > We found a bug reachable in:
> >
> >     path    drivers/usb/host
> >     crash   out-of-bounds in xhci_queue_bulk_tx()
> >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> >
> > Config, environment, the sanitizer report and a C reproducer follow.
> >
> > == Notes ===============================================================
> >     If you patch the bug based on our artifacts, a tag would be
> >     appreciated:
> >
> > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> >
> >     Everything in this mail is validated by the reproducer below.
> >
> >     We also hold an LLM-generated root-cause analysis and a candidate
> >     patch. The patch passes an A/B test: the same reproducer panics the
> >     unpatched kernel and runs clean on the patched one. Neither has had
> >     human review, so both still require validation before you send or
> >     apply them. Available on:
> >
> >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
>
> Please validate and ensure that this is correct before sending this to
> us.  No need for us to dig through random web links, right?
>
Thanks for your feedback, Greg.

We are working on making reports public. Sorry for the inconvenience.
We'll stop sending bug reports before we fix the issue.

Xiang

> thanks,
>
> greg k-h
>

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Michal Pecio]

On Thu, 27 Aug 2026 12:43:58 +0000, co wrote:
> We found a bug reachable in:
> 
>     path    drivers/usb/host
>     crash   out-of-bounds in xhci_queue_bulk_tx()
>     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> 
> Config, environment, the sanitizer report and a C reproducer follow.
> 
> == Notes ===============================================================
>     If you patch the bug based on our artifacts, a tag would be
>     appreciated:
> 
> Reported-by: co+fd80bc5967eb22c3@bugs.sh
> 
>     Everything in this mail is validated by the reproducer below.
> 
>     We also hold an LLM-generated root-cause analysis and a candidate
>     patch. The patch passes an A/B test: the same reproducer panics the
>     unpatched kernel and runs clean on the patched one. Neither has had
>     human review, so both still require validation before you send or
>     apply them. Available on:
> 
>         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
>         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md

I for one have clicked that random web link, the patch boils down to

-       max_pkt = xhci_usb_endpoint_maxp(urb->dev, urb->ep);
+       max_pkt = ring->bounce_buf_len;

and sure, xhci_usb_endpoint_maxp() returns the "raw" out of spec value
from the descriptor, while bounce_buf_len is "sanitized", which means a
constant value of 512 for high-speed devices, since the driver doesn't
actually use out of spec max packet sizes on bulk endpoints (except for
SuperSpeed?), see xhci_endpoint_init().

The sanitized value is used to size bounce buffers and also programmed
into the HW, so it would make sense to use it here too.

And if anyone wonders how such a descriptor can reach HCDs,

  fb5ee84ea72c USB: Accept bulk endpoints with 1024-byte maxpacket

So this kind of weird device (no idea what they are) plus bad luck with
its driver submitting scatter-gather URBs could result in a bad day.

Regards,
Michal

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[CO]

On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
>
> Th
>
> On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > We found a bug reachable in:
> > >
> > >     path    drivers/usb/host
> > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > >
> > > Config, environment, the sanitizer report and a C reproducer follow.
> > >
> > > == Notes ===============================================================
> > >     If you patch the bug based on our artifacts, a tag would be
> > >     appreciated:
> > >
> > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > >
> > >     Everything in this mail is validated by the reproducer below.
> > >
> > >     We also hold an LLM-generated root-cause analysis and a candidate
> > >     patch. The patch passes an A/B test: the same reproducer panics the
> > >     unpatched kernel and runs clean on the patched one. Neither has had
> > >     human review, so both still require validation before you send or
> > >     apply them. Available on:
> > >
> > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> >
> > Please validate and ensure that this is correct before sending this to
> > us.  No need for us to dig through random web links, right?
Hi Greg,

Thanks for the feedback, and sorry for the noise. Sending these before
we had settled the format and talked to maintainers was our mistake.

Let me make sure we understood your suggestions.

# What we understood

You want patches that a human has verified, and you do not want to
have to follow links to find out what a report says. We should not
have sent what we sent.

# Where we are

We want to help secure the kernel without wasting anyone's time. For
the past year we fixed our own bugs by hand, so we know what a patch
costs you: days of review and discussion before it is clean. We are
grateful for that, and it is why we do not want to send anything we
have not checked.

What we can check is the reproduction, and we do: we build the kernel
at the commit named in the report, with the config in it, boot it, run
the PoC, and see the crash we quote.

What we cannot check, at the rate our LLM pipeline now finds bugs, is
the patch. Judging whether a fix is right for a subsystem needs someone
who knows that code, and we do not have those hours. So we would rather
report the bug and leave the fix to its maintainers, the way syzbot
does.

On the links, we would ask your understanding. We link the config and
the reproducer rather than inline them because both are long: the
config is around 250KB and the PoC runs to a few hundred lines. The
links point at bugs.sh, which is served from a public GitHub repo.
The crash itself is in the mail, and we can inline the reproducer
too if you would prefer that.

We also cannot host built kernels the way syzbot does, so what we give
instead is the exact commit and the config. We are working on a tool
that reproduces a bug straight from the information in a report, so
that this costs maintainers less time.

# What we would like to ask

- the format: is a report that links its config and reproducer
  acceptable to you, or would you rather have everything in the mail
  body? We can do either.

- would a report with no patch in it be useful to you? That is: the
  bug, a PoC, the environment to reproduce it in, and the crash we
  expect, without a validated patch.

- do you want to see the generated patch in the body of the report
  instead of behind a link? Either way it would be labelled for what
  it is: an example of a change that stops the crash, not a fix we are
  proposing for merge. Our default is to leave it out.

- the report.md link in the mails you received was meant to point at a
  short root-cause note the model wrote while it was writing the PoC.
  It was broken; this is the fixed one:

    https://bugs.sh/b/fd80bc5967eb22c3/report.md

Is such a note worth having in a report at all? It is in the same
category as the patch, in that it may simply be wrong.

# Until then

We have stopped. No further reports go out until the format is one
that does not waste your time. 19 reports went out in a single batch
without a person releasing them, which was our process failure.
That is fixed, and we would rather settle the format with you before
we start again.

We respect the time contributors put into the Linux kernel, and we do
not want to become a new drain on it. We appreciate any suggestions
from you.

Xiang Mei
> >
> Thanks for your feedback, Greg.
>
> We are working on making reports public. Sorry for the inconvenience.
> We'll stop sending bug reports before we fix the issue.
>
> Xiang
>
> > thanks,
> >
> > greg k-h
> >
>

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg KH]

On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> >
> > Th
> >
> > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > We found a bug reachable in:
> > > >
> > > >     path    drivers/usb/host
> > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > >
> > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > >
> > > > == Notes ===============================================================
> > > >     If you patch the bug based on our artifacts, a tag would be
> > > >     appreciated:
> > > >
> > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > >
> > > >     Everything in this mail is validated by the reproducer below.
> > > >
> > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > >     human review, so both still require validation before you send or
> > > >     apply them. Available on:
> > > >
> > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > >
> > > Please validate and ensure that this is correct before sending this to
> > > us.  No need for us to dig through random web links, right?
> Hi Greg,
> 
> Thanks for the feedback, and sorry for the noise. Sending these before
> we had settled the format and talked to maintainers was our mistake.
> 
> Let me make sure we understood your suggestions.
> 
> # What we understood
> 
> You want patches that a human has verified, and you do not want to
> have to follow links to find out what a report says. We should not
> have sent what we sent.

That is correct, would you want anything different if we were to send
stuff to you?

> # Until then
> 
> We have stopped. No further reports go out until the format is one
> that does not waste your time. 19 reports went out in a single batch
> without a person releasing them, which was our process failure.
> That is fixed, and we would rather settle the format with you before
> we start again.

Just use our normal development process of sending patches, there's no
need to change anything here as it's working quite well (fastest rate of
change of any project with the most contributors...)

thanks,

greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[CO]

On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
>
> On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > >
> > > Th
> > >
> > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > We found a bug reachable in:
> > > > >
> > > > >     path    drivers/usb/host
> > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > >
> > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > >
> > > > > == Notes ===============================================================
> > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > >     appreciated:
> > > > >
> > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > >
> > > > >     Everything in this mail is validated by the reproducer below.
> > > > >
> > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > >     human review, so both still require validation before you send or
> > > > >     apply them. Available on:
> > > > >
> > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > >
> > > > Please validate and ensure that this is correct before sending this to
> > > > us.  No need for us to dig through random web links, right?
> > Hi Greg,
> >
> > Thanks for the feedback, and sorry for the noise. Sending these before
> > we had settled the format and talked to maintainers was our mistake.
> >
> > Let me make sure we understood your suggestions.
> >
> > # What we understood
> >
> > You want patches that a human has verified, and you do not want to
> > have to follow links to find out what a report says. We should not
> > have sent what we sent.
>
> That is correct, would you want anything different if we were to send
> stuff to you?
>

Nothing in particular, thanks. A Reported-by: tag and having the
report closed would be appreciated!

> > # Until then
> >
> > We have stopped. No further reports go out until the format is one
> > that does not waste your time. 19 reports went out in a single batch
> > without a person releasing them, which was our process failure.
> > That is fixed, and we would rather settle the format with you before
> > we start again.
>
> Just use our normal development process of sending patches, there's no
> need to change anything here as it's working quite well (fastest rate of
> change of any project with the most contributors...)
>
> thanks,
>
> greg k-h
>
Understood, thanks. We will be slow at first and keep things small-scale, and
improve our workflow by checking the requirements from the replies. Thanks
for your effort and for taking the time to help us get this right.


Xiang

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg KH]

On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> >
> > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > >
> > > > Th
> > > >
> > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > We found a bug reachable in:
> > > > > >
> > > > > >     path    drivers/usb/host
> > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > >
> > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > >
> > > > > > == Notes ===============================================================
> > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > >     appreciated:
> > > > > >
> > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > >
> > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > >
> > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > >     human review, so both still require validation before you send or
> > > > > >     apply them. Available on:
> > > > > >
> > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > >
> > > > > Please validate and ensure that this is correct before sending this to
> > > > > us.  No need for us to dig through random web links, right?
> > > Hi Greg,
> > >
> > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > we had settled the format and talked to maintainers was our mistake.
> > >
> > > Let me make sure we understood your suggestions.
> > >
> > > # What we understood
> > >
> > > You want patches that a human has verified, and you do not want to
> > > have to follow links to find out what a report says. We should not
> > > have sent what we sent.
> >
> > That is correct, would you want anything different if we were to send
> > stuff to you?
> >
> 
> Nothing in particular, thanks. A Reported-by: tag and having the
> report closed would be appreciated!

If you submit a patch, you are the author and no reported-by is then
needed.

And we don't have anything to "close", so that's not really going to be
possible :)

thanks,

greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Cedalion]

On Fri, Aug 28, 2026 at 11:20 PM Greg KH <greg@kroah.com> wrote:
>
> On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> > On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > > >
> > > > > Th
> > > > >
> > > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > > We found a bug reachable in:
> > > > > > >
> > > > > > >     path    drivers/usb/host
> > > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > > >
> > > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > > >
> > > > > > > == Notes ===============================================================
> > > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > > >     appreciated:
> > > > > > >
> > > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > > >
> > > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > > >
> > > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > > >     human review, so both still require validation before you send or
> > > > > > >     apply them. Available on:
> > > > > > >
> > > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > > >
> > > > > > Please validate and ensure that this is correct before sending this to
> > > > > > us.  No need for us to dig through random web links, right?
> > > > Hi Greg,
> > > >
> > > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > > we had settled the format and talked to maintainers was our mistake.
> > > >
> > > > Let me make sure we understood your suggestions.
> > > >
> > > > # What we understood
> > > >
> > > > You want patches that a human has verified, and you do not want to
> > > > have to follow links to find out what a report says. We should not
> > > > have sent what we sent.
> > >
> > > That is correct, would you want anything different if we were to send
> > > stuff to you?
> > >
> >
> > Nothing in particular, thanks. A Reported-by: tag and having the
> > report closed would be appreciated!
>
> If you submit a patch, you are the author and no reported-by is then
> needed.
>

Thanks, that makes sense when we send patches. We want to focus on bug
reporting for now like syzbot and we'll also put our time in patching
when the pipeline can run stablly.

> And we don't have anything to "close", so that's not really going to be
> possible :)
>
Sorry for my typo, I meant the `Closes:` tag, but it is fine either
way if it is left out.
As long as our report helps to locate a bug in an efficient way, we are happy.

Xiang
> thanks,
>
> greg k-h
>

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg KH]

On Fri, Aug 28, 2026 at 11:42:07PM -0700, Cedalion wrote:
> On Fri, Aug 28, 2026 at 11:20 PM Greg KH <greg@kroah.com> wrote:
> >
> > On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> > > On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> > > >
> > > > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > > > >
> > > > > > Th
> > > > > >
> > > > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > > > We found a bug reachable in:
> > > > > > > >
> > > > > > > >     path    drivers/usb/host
> > > > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > > > >
> > > > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > > > >
> > > > > > > > == Notes ===============================================================
> > > > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > > > >     appreciated:
> > > > > > > >
> > > > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > > > >
> > > > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > > > >
> > > > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > > > >     human review, so both still require validation before you send or
> > > > > > > >     apply them. Available on:
> > > > > > > >
> > > > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > > > >
> > > > > > > Please validate and ensure that this is correct before sending this to
> > > > > > > us.  No need for us to dig through random web links, right?
> > > > > Hi Greg,
> > > > >
> > > > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > > > we had settled the format and talked to maintainers was our mistake.
> > > > >
> > > > > Let me make sure we understood your suggestions.
> > > > >
> > > > > # What we understood
> > > > >
> > > > > You want patches that a human has verified, and you do not want to
> > > > > have to follow links to find out what a report says. We should not
> > > > > have sent what we sent.
> > > >
> > > > That is correct, would you want anything different if we were to send
> > > > stuff to you?
> > > >
> > >
> > > Nothing in particular, thanks. A Reported-by: tag and having the
> > > report closed would be appreciated!
> >
> > If you submit a patch, you are the author and no reported-by is then
> > needed.
> >
> 
> Thanks, that makes sense when we send patches. We want to focus on bug
> reporting for now like syzbot and we'll also put our time in patching
> when the pipeline can run stablly.

We almost always ignore "bug reports" that don't come with patches,
especially as your tool (i.e. your LLM) can automatically generate a
patch based on your reproducer, so why not submit it?

thanks,

greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[CO]

On Sat, Aug 29, 2026 at 12:01 AM Greg KH <greg@kroah.com> wrote:
>
> On Fri, Aug 28, 2026 at 11:42:07PM -0700, Cedalion wrote:
> > On Fri, Aug 28, 2026 at 11:20 PM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> > > > On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> > > > >
> > > > > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > > > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > > > > >
> > > > > > > Th
> > > > > > >
> > > > > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > > > > We found a bug reachable in:
> > > > > > > > >
> > > > > > > > >     path    drivers/usb/host
> > > > > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > > > > >
> > > > > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > > > > >
> > > > > > > > > == Notes ===============================================================
> > > > > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > > > > >     appreciated:
> > > > > > > > >
> > > > > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > > > > >
> > > > > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > > > > >
> > > > > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > > > > >     human review, so both still require validation before you send or
> > > > > > > > >     apply them. Available on:
> > > > > > > > >
> > > > > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > > > > >
> > > > > > > > Please validate and ensure that this is correct before sending this to
> > > > > > > > us.  No need for us to dig through random web links, right?
> > > > > > Hi Greg,
> > > > > >
> > > > > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > > > > we had settled the format and talked to maintainers was our mistake.
> > > > > >
> > > > > > Let me make sure we understood your suggestions.
> > > > > >
> > > > > > # What we understood
> > > > > >
> > > > > > You want patches that a human has verified, and you do not want to
> > > > > > have to follow links to find out what a report says. We should not
> > > > > > have sent what we sent.
> > > > >
> > > > > That is correct, would you want anything different if we were to send
> > > > > stuff to you?
> > > > >
> > > >
> > > > Nothing in particular, thanks. A Reported-by: tag and having the
> > > > report closed would be appreciated!
> > >
> > > If you submit a patch, you are the author and no reported-by is then
> > > needed.
> > >
> >
> > Thanks, that makes sense when we send patches. We want to focus on bug
> > reporting for now like syzbot and we'll also put our time in patching
> > when the pipeline can run stablly.
>
> We almost always ignore "bug reports" that don't come with patches,

Understood. A bug with a human-validated patch is worth far more than
a report alone.

> especially as your tool (i.e. your LLM) can automatically generate a
> patch based on your reproducer, so why not submit it?
>

The bottleneck isn't generating a patch, it's validating one. Bug
reporting scales because a reproducer is self-validating: either the
kernel crashes or it doesn't. A patch isn't. We can confirm a patch
stops the crash via A/B testing, but confirming it addresses the
actual root cause rather than papering over a symptom is beyond what
LLMs can do automatically today. In our experience current LLMs don't
come close to an experienced maintainer, and sending patches we didn't
validate would just move our validation cost onto reviewers.

If untriaged patches are still useful, we're happy to
include them. We would send a proper patch with a commit message
rather than a bare diff, clearly marked as LLM-generated and
A/B-tested only, so it's obvious what has and hasn't been verified and
others can take it further if they want.

If instead you'd prefer we only send patches we've reviewed by hand,
we'll keep doing that, just at a much lower rate, since it's two of
us.

Thanks,
Xiang
> thanks,
>
> greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg KH]

On Sat, Aug 29, 2026 at 07:34:24AM +0000, CO wrote:
> On Sat, Aug 29, 2026 at 12:01 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Fri, Aug 28, 2026 at 11:42:07PM -0700, Cedalion wrote:
> > > On Fri, Aug 28, 2026 at 11:20 PM Greg KH <greg@kroah.com> wrote:
> > > >
> > > > On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> > > > > On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> > > > > >
> > > > > > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > > > > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > > > > > >
> > > > > > > > Th
> > > > > > > >
> > > > > > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > > > > > We found a bug reachable in:
> > > > > > > > > >
> > > > > > > > > >     path    drivers/usb/host
> > > > > > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > > > > > >
> > > > > > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > > > > > >
> > > > > > > > > > == Notes ===============================================================
> > > > > > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > > > > > >     appreciated:
> > > > > > > > > >
> > > > > > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > > > > > >
> > > > > > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > > > > > >
> > > > > > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > > > > > >     human review, so both still require validation before you send or
> > > > > > > > > >     apply them. Available on:
> > > > > > > > > >
> > > > > > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > > > > > >
> > > > > > > > > Please validate and ensure that this is correct before sending this to
> > > > > > > > > us.  No need for us to dig through random web links, right?
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > > > > > we had settled the format and talked to maintainers was our mistake.
> > > > > > >
> > > > > > > Let me make sure we understood your suggestions.
> > > > > > >
> > > > > > > # What we understood
> > > > > > >
> > > > > > > You want patches that a human has verified, and you do not want to
> > > > > > > have to follow links to find out what a report says. We should not
> > > > > > > have sent what we sent.
> > > > > >
> > > > > > That is correct, would you want anything different if we were to send
> > > > > > stuff to you?
> > > > > >
> > > > >
> > > > > Nothing in particular, thanks. A Reported-by: tag and having the
> > > > > report closed would be appreciated!
> > > >
> > > > If you submit a patch, you are the author and no reported-by is then
> > > > needed.
> > > >
> > >
> > > Thanks, that makes sense when we send patches. We want to focus on bug
> > > reporting for now like syzbot and we'll also put our time in patching
> > > when the pipeline can run stablly.
> >
> > We almost always ignore "bug reports" that don't come with patches,
> 
> Understood. A bug with a human-validated patch is worth far more than
> a report alone.
> 
> > especially as your tool (i.e. your LLM) can automatically generate a
> > patch based on your reproducer, so why not submit it?
> >
> 
> The bottleneck isn't generating a patch, it's validating one. Bug
> reporting scales because a reproducer is self-validating: either the
> kernel crashes or it doesn't. A patch isn't. We can confirm a patch
> stops the crash via A/B testing, but confirming it addresses the
> actual root cause rather than papering over a symptom is beyond what
> LLMs can do automatically today. In our experience current LLMs don't
> come close to an experienced maintainer, and sending patches we didn't
> validate would just move our validation cost onto reviewers.

Agreed, so don't do that, but rather:

> If untriaged patches are still useful, we're happy to
> include them. We would send a proper patch with a commit message
> rather than a bare diff, clearly marked as LLM-generated and
> A/B-tested only, so it's obvious what has and hasn't been verified and
> others can take it further if they want.

No, please do:

> If instead you'd prefer we only send patches we've reviewed by hand,
> we'll keep doing that, just at a much lower rate, since it's two of
> us.

Yes, review them by hand, verify they are correct, and then send them to
us based on your review.  For you to expect us to do your work for you
is a bit odd, don't you think?

We want fixes that people think are correct, based on their review and
testing.  Based on the work I've been doing this year, LLM-generated
stuff is 50% the time totally wrong.  Don't make me have to reject your
LLM-generated patches 50% the time, as we will just get frustrated and
ignore 100% of your submitted patches :)

thanks,

greg k-h

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[CO]

Sorry for the late reply, and thanks for the clear answer.

On Sat, Aug 29, 2026 at 12:55 AM Greg KH <greg@kroah.com> wrote:
>
> On Sat, Aug 29, 2026 at 07:34:24AM +0000, CO wrote:
> > On Sat, Aug 29, 2026 at 12:01 AM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Fri, Aug 28, 2026 at 11:42:07PM -0700, Cedalion wrote:
> > > > On Fri, Aug 28, 2026 at 11:20 PM Greg KH <greg@kroah.com> wrote:
> > > > >
> > > > > On Sat, Aug 29, 2026 at 06:07:39AM +0000, CO wrote:
> > > > > > On Thu, Aug 27, 2026 at 10:36 PM Greg KH <greg@kroah.com> wrote:
> > > > > > >
> > > > > > > On Fri, Aug 28, 2026 at 02:00:17AM +0000, CO wrote:
> > > > > > > > On Thu, Aug 27, 2026 at 10:31 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > > > > > > >
> > > > > > > > > Th
> > > > > > > > >
> > > > > > > > > On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> > > > > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Aug 27, 2026 at 12:43:58PM +0000, co wrote:
> > > > > > > > > > > We found a bug reachable in:
> > > > > > > > > > >
> > > > > > > > > > >     path    drivers/usb/host
> > > > > > > > > > >     crash   out-of-bounds in xhci_queue_bulk_tx()
> > > > > > > > > > >     commit  bd5f485f3f02 ("Merge tag 'soc-arm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc")
> > > > > > > > > > >
> > > > > > > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > > > > > > >
> > > > > > > > > > > == Notes ===============================================================
> > > > > > > > > > >     If you patch the bug based on our artifacts, a tag would be
> > > > > > > > > > >     appreciated:
> > > > > > > > > > >
> > > > > > > > > > > Reported-by: co+fd80bc5967eb22c3@bugs.sh
> > > > > > > > > > >
> > > > > > > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > > > > > > >
> > > > > > > > > > >     We also hold an LLM-generated root-cause analysis and a candidate
> > > > > > > > > > >     patch. The patch passes an A/B test: the same reproducer panics the
> > > > > > > > > > >     unpatched kernel and runs clean on the patched one. Neither has had
> > > > > > > > > > >     human review, so both still require validation before you send or
> > > > > > > > > > >     apply them. Available on:
> > > > > > > > > > >
> > > > > > > > > > >         patch.diff  https://bugs.sh/b/fd80bc5967eb22c3/patch.diff
> > > > > > > > > > >         report.md   https://bugs.sh/b/fd80bc5967eb22c3/report.md
> > > > > > > > > >
> > > > > > > > > > Please validate and ensure that this is correct before sending this to
> > > > > > > > > > us.  No need for us to dig through random web links, right?
> > > > > > > > Hi Greg,
> > > > > > > >
> > > > > > > > Thanks for the feedback, and sorry for the noise. Sending these before
> > > > > > > > we had settled the format and talked to maintainers was our mistake.
> > > > > > > >
> > > > > > > > Let me make sure we understood your suggestions.
> > > > > > > >
> > > > > > > > # What we understood
> > > > > > > >
> > > > > > > > You want patches that a human has verified, and you do not want to
> > > > > > > > have to follow links to find out what a report says. We should not
> > > > > > > > have sent what we sent.
> > > > > > >
> > > > > > > That is correct, would you want anything different if we were to send
> > > > > > > stuff to you?
> > > > > > >
> > > > > >
> > > > > > Nothing in particular, thanks. A Reported-by: tag and having the
> > > > > > report closed would be appreciated!
> > > > >
> > > > > If you submit a patch, you are the author and no reported-by is then
> > > > > needed.
> > > > >
> > > >
> > > > Thanks, that makes sense when we send patches. We want to focus on bug
> > > > reporting for now like syzbot and we'll also put our time in patching
> > > > when the pipeline can run stablly.
> > >
> > > We almost always ignore "bug reports" that don't come with patches,
> >
> > Understood. A bug with a human-validated patch is worth far more than
> > a report alone.
> >
> > > especially as your tool (i.e. your LLM) can automatically generate a
> > > patch based on your reproducer, so why not submit it?
> > >
> >
> > The bottleneck isn't generating a patch, it's validating one. Bug
> > reporting scales because a reproducer is self-validating: either the
> > kernel crashes or it doesn't. A patch isn't. We can confirm a patch
> > stops the crash via A/B testing, but confirming it addresses the
> > actual root cause rather than papering over a symptom is beyond what
> > LLMs can do automatically today. In our experience current LLMs don't
> > come close to an experienced maintainer, and sending patches we didn't
> > validate would just move our validation cost onto reviewers.
>
> Agreed, so don't do that, but rather:
>
> > If untriaged patches are still useful, we're happy to
> > include them. We would send a proper patch with a commit message
> > rather than a bare diff, clearly marked as LLM-generated and
> > A/B-tested only, so it's obvious what has and hasn't been verified and
> > others can take it further if they want.
>
> No, please do:
>
> > If instead you'd prefer we only send patches we've reviewed by hand,
> > we'll keep doing that, just at a much lower rate, since it's two of
> > us.
>
> Yes, review them by hand, verify they are correct, and then send them to
> us based on your review.  For you to expect us to do your work for you
> is a bit odd, don't you think?
>
> We want fixes that people think are correct, based on their review and
> testing.  Based on the work I've been doing this year, LLM-generated
> stuff is 50% the time totally wrong.  Don't make me have to reject your
> LLM-generated patches 50% the time, as we will just get frustrated and
> ignore 100% of your submitted patches :)
>

I 100% agree with you.  We won't send patches we haven't reviewed ourselves.

> thanks,
>
> greg k-h
>


I'd like to check something:

Is it acceptable to send bug reports (without a patch, such as this
bug report) to the list like syzbot?

As you mentioned, we understand many of them will be ignored since
reviewers would prioritize patches. But we'll work with community
contributors who would like to work to write a patch for them. (which
faster than just two of us)

Thanks again,
Xiang

Re: [BUG] drivers/usb: out-of-bounds in xhci_queue_bulk_tx()

[Greg KH]

On Tue, Sep 01, 2026 at 12:23:12PM +0000, CO wrote:
> Is it acceptable to send bug reports (without a patch, such as this
> bug report) to the list like syzbot?

I can't tell anyone what to do, but if you have found a bug, it's
usually best to submit a patch to fix it, as you have a reproducer so
you can test it better than anyone, right?

> As you mentioned, we understand many of them will be ignored since
> reviewers would prioritize patches. But we'll work with community
> contributors who would like to work to write a patch for them. (which
> faster than just two of us)

These days you can feed a bug report into a local LLM and get out a
first-cut of a patch quite easily.

But sure, posting bug reports is fine, but again, patches are better :)

thanks,

greg k-h

[PATCH] usb: xhci: Fix bounce buffer overflow

[Michal Pecio]

High-speed devices with out of spec 1024 byte bulk endpoints exist and
are allowed by USB core, but xhci-hcd always sets packet size to 512.
The exact nature of these devices isn't documented, commit fb5ee84ea72c
("USB: Accept bulk endpoints with 1024-byte maxpacket") only states
that they "don't work with xHCI host controllers", whatever it means.

But somebody (or a malicious device) can try, and then the driver will
allocate a 512 byte bounce buffer for this endpoint and may write up to
1024 bytes into it if particular scatter-gather URBs are used, because
xhci_align_td() obtains packet size from the descriptor. Fix this.

As a side effect, TRBs will be aligned to the packet size chosen by the
driver on all endpoints of all speeds. Alignment serves the xHC, not
device, so this is fine. Only out of spec devices are affected anyway.

Reported-by: co+fd80bc5967eb22c3@bugs.sh
Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable@vger.kernel.org
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---

Trivial bug, trivial patch, though only tested for regression with
an in-spec device, testing with the malicious device would be helpful
to confirm that memory corruption is gone as expected.

As for actual devices with 1KB packet size, I found that Cypress FX2
can generate such packets and some HCs receive them, though others
reject the Configure Endpoint command and usb_set_interface() fails.

So we could support that, but this code really should just use the
packet size selected by the driver instead of guessing.

Perhaps the same should apply to other users of endpoint_maxp(), but
those just calculate some TRB fields like TD Size, nothing critical.

 drivers/usb/host/xhci-ring.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b9d005ca5877..fa6684746305 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3537,15 +3537,13 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
 
 
 static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len,
-			 u32 *trb_buff_len, struct xhci_segment *seg)
+			 u32 *trb_buff_len, struct xhci_segment *seg, u32 max_pkt)
 {
 	struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 	unsigned int unalign;
-	unsigned int max_pkt;
 	u32 new_buff_len;
 	size_t len;
 
-	max_pkt = xhci_usb_endpoint_maxp(urb->dev, urb->ep);
 	unalign = (enqd_len + *trb_buff_len) % max_pkt;
 
 	/* we got lucky, last normal TRB data on segment is packet aligned */
@@ -3690,9 +3688,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
 		if (enqd_len + trb_buff_len < full_len) {
 			field |= TRB_CHAIN;
 			if (trb_is_link(ring->enqueue + 1)) {
-				if (xhci_align_td(xhci, urb, enqd_len,
-						  &trb_buff_len,
-						  ring->enq_seg)) {
+				if (xhci_align_td(xhci, urb, enqd_len, &trb_buff_len,
+						ring->enq_seg, ring->bounce_buf_len)) {
 					send_addr = ring->enq_seg->bounce_dma;
 					/* TD bounced at least, and last on this seg */
 					td->bounce_seg = ring->enq_seg;
-- 
2.48.1

Re: [PATCH] usb: xhci: Fix bounce buffer overflow

[Mathias Nyman]

On 9/2/26 14:24, Michal Pecio wrote:
> High-speed devices with out of spec 1024 byte bulk endpoints exist and
> are allowed by USB core, but xhci-hcd always sets packet size to 512.
> The exact nature of these devices isn't documented, commit fb5ee84ea72c
> ("USB: Accept bulk endpoints with 1024-byte maxpacket") only states
> that they "don't work with xHCI host controllers", whatever it means.
> 
> But somebody (or a malicious device) can try, and then the driver will
> allocate a 512 byte bounce buffer for this endpoint and may write up to
> 1024 bytes into it if particular scatter-gather URBs are used, because
> xhci_align_td() obtains packet size from the descriptor. Fix this.
> 
> As a side effect, TRBs will be aligned to the packet size chosen by the
> driver on all endpoints of all speeds. Alignment serves the xHC, not
> device, so this is fine. Only out of spec devices are affected anyway.
> 
> Reported-by: co+fd80bc5967eb22c3@bugs.sh
> Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/
> Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
> Cc: stable@vger.kernel.org
> Signed-off-by: Michal Pecio <michal.pecio@gmail.com>

Thanks, added to queue

-Mathias