[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