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@xxxxxxx> wrote:
>
> Th
>
> On Thu, Aug 27, 2026 at 5:50 AM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxx
> > >
> > >     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
> >
>