[BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[co]

This is a bug report, not a patch submission. See
https://bugs.sh/reporting.html

We found a bug reachable in:

    path    drivers/usb/usbip
    crash   NULL pointer dereference in stub_recv_cmd_submit()
    commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")

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

== Notes ===============================================================
    If you fix this bug, this tag credits the report and lets us
    close it on our side:

Reported-by: co+66c3f58096d0bde8@bugs.sh

    Everything in this mail is validated by the reproducer below.

    We also hold an unreviewed LLM-generated analysis and candidate
    patch. The same reproducer panics the unpatched kernel and runs
    clean with that patch applied. Use it as a starting point, or ignore
    it and write your own:

        patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
        report.md   https://bugs.sh/b/66c3f58096d0bde8/report.md

    A guide to taking it from here to a sendable patch, including the
    trailers to add: https://bugs.sh/patch.html

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

        cedalion@bugs.sh

== Environment =========================================================
    Reproduced on  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
    VM setup       https://bugs.sh/b/66c3f58096d0bde8/run.sh
    config         https://bugs.sh/b/66c3f58096d0bde8/config.gz
    poc            https://bugs.sh/b/66c3f58096d0bde8/repro.c

== Sanitizer Report ====================================================
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 83 Comm: kworker/u8:5 Not tainted 7.2.0 #1 PREEMPT(full)
Workqueue: usbip_event event_handler
RIP: 0010:stub_device_cleanup_urbs (drivers/usb/usbip/stub_main.c:356)
Call Trace:
stub_shutdown_connection (drivers/usb/usbip/stub_dev.c:191)
event_handler (drivers/usb/usbip/usbip_event.c:79)
process_one_work (kernel/workqueue.c:3322)
worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Kernel panic - not syncing: Fatal exception


---
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: NULL pointer dereference in stub_recv_cmd_submit()

[Greg Kroah-Hartman]

On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> This is a bug report, not a patch submission. See
> https://bugs.sh/reporting.html
> 
> We found a bug reachable in:
> 
>     path    drivers/usb/usbip
>     crash   NULL pointer dereference in stub_recv_cmd_submit()
>     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> 
> Config, environment, the sanitizer report and a C reproducer follow.
> 
> == Notes ===============================================================
>     If you fix this bug, this tag credits the report and lets us
>     close it on our side:
> 
> Reported-by: co+66c3f58096d0bde8@bugs.sh
> 
>     Everything in this mail is validated by the reproducer below.
> 
>     We also hold an unreviewed LLM-generated analysis and candidate
>     patch. The same reproducer panics the unpatched kernel and runs
>     clean with that patch applied. Use it as a starting point, or ignore
>     it and write your own:
> 
>         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff

Please just submit patches like normal, in a format that can be applied,
and do not make us go to random links to attempt to get any information.
That's not how kernel development works at all.

thanks,

greg k-h

Re: [BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[Xiang Mei]

On Fri, Sep 11, 2026 at 10:47 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> > This is a bug report, not a patch submission. See
> > https://bugs.sh/reporting.html
> >
> > We found a bug reachable in:
> >
> >     path    drivers/usb/usbip
> >     crash   NULL pointer dereference in stub_recv_cmd_submit()
> >     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> >
> > Config, environment, the sanitizer report and a C reproducer follow.
> >
> > == Notes ===============================================================
> >     If you fix this bug, this tag credits the report and lets us
> >     close it on our side:
> >
> > Reported-by: co+66c3f58096d0bde8@bugs.sh
> >
> >     Everything in this mail is validated by the reproducer below.
> >
> >     We also hold an unreviewed LLM-generated analysis and candidate
> >     patch. The same reproducer panics the unpatched kernel and runs
> >     clean with that patch applied. Use it as a starting point, or ignore
> >     it and write your own:
> >
> >         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
>
> Please just submit patches like normal, in a format that can be applied,
> and do not make us go to random links to attempt to get any information.
> That's not how kernel development works at all.
>

Hi Greg,

Sorry about this. We may have misunderstood your earlier reply in this thread:

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

https://lore.kernel.org/all/2026090139-shortlist-junkie-9bee@gregkh/#t

We interpreted this as meaning that sending bug reports without
patches was acceptable. We understand your concern with the current
format, and we will stop sending reports in this format to you and
linux-usb@vger.kernel.org.

To make sure we understand correctly and follow the appropriate
practice going forward, should we:

1. Send pure bug reports without any LLM-generated analysis or
candidate patch, similar to the bug reports syzbot sends to kernel
mailing lists;
2. For USB, do not send bug reports and only submit patches in the
normal kernel format; or
3. More generally, do not send bug reports to Linux kernel mailing
lists and only submit patches in the normal kernel format?

Sorry again for the misunderstanding, and thanks for taking the time
to clarify this despite your busy schedule.

Xiang

> thanks,
>
> greg k-h
>

Re: [BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[Greg Kroah-Hartman]

On Sat, Sep 12, 2026 at 11:41:00AM -0700, Xiang Mei wrote:
> On Fri, Sep 11, 2026 at 10:47 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> > > This is a bug report, not a patch submission. See
> > > https://bugs.sh/reporting.html
> > >
> > > We found a bug reachable in:
> > >
> > >     path    drivers/usb/usbip
> > >     crash   NULL pointer dereference in stub_recv_cmd_submit()
> > >     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> > >
> > > Config, environment, the sanitizer report and a C reproducer follow.
> > >
> > > == Notes ===============================================================
> > >     If you fix this bug, this tag credits the report and lets us
> > >     close it on our side:
> > >
> > > Reported-by: co+66c3f58096d0bde8@bugs.sh
> > >
> > >     Everything in this mail is validated by the reproducer below.
> > >
> > >     We also hold an unreviewed LLM-generated analysis and candidate
> > >     patch. The same reproducer panics the unpatched kernel and runs
> > >     clean with that patch applied. Use it as a starting point, or ignore
> > >     it and write your own:
> > >
> > >         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
> >
> > Please just submit patches like normal, in a format that can be applied,
> > and do not make us go to random links to attempt to get any information.
> > That's not how kernel development works at all.
> >
> 
> Hi Greg,
> 
> Sorry about this. We may have misunderstood your earlier reply in this thread:
> 
> "But sure, posting bug reports is fine, but again, patches are better :)"
> 
> https://lore.kernel.org/all/2026090139-shortlist-junkie-9bee@gregkh/#t
> 
> We interpreted this as meaning that sending bug reports without
> patches was acceptable. We understand your concern with the current
> format, and we will stop sending reports in this format to you and
> linux-usb@vger.kernel.org.
> 
> To make sure we understand correctly and follow the appropriate
> practice going forward, should we:
> 
> 1. Send pure bug reports without any LLM-generated analysis or
> candidate patch, similar to the bug reports syzbot sends to kernel
> mailing lists;
> 2. For USB, do not send bug reports and only submit patches in the
> normal kernel format; or
> 3. More generally, do not send bug reports to Linux kernel mailing
> lists and only submit patches in the normal kernel format?
> 
> Sorry again for the misunderstanding, and thanks for taking the time
> to clarify this despite your busy schedule.

Think about what _you_ would want to see if you were on the receiving
end of hundreds of patches a week.  Would you want to see a vague email
with links required to dig stuff out to potentially have to make up a
fix yourself for an unknown and poorly worded description, or would you
want a real patch, in mergable format, that describes the problem and
how it is being resolved?

I think the latter :)

Right now, most developers just ignore syzbot reports, as we are
drowning in real fixes from developers instead.  There's no need for us
to go research new fixes when we are having a hard time keeping on top
of the stuff people are sending us that are in mergable state already!

thanks,

greg k-h

Re: [BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[Xiang Mei]

On Sun, Sep 13, 2026 at 2:19 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sat, Sep 12, 2026 at 11:41:00AM -0700, Xiang Mei wrote:
> > On Fri, Sep 11, 2026 at 10:47 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> > > > This is a bug report, not a patch submission. See
> > > > https://bugs.sh/reporting.html
> > > >
> > > > We found a bug reachable in:
> > > >
> > > >     path    drivers/usb/usbip
> > > >     crash   NULL pointer dereference in stub_recv_cmd_submit()
> > > >     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> > > >
> > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > >
> > > > == Notes ===============================================================
> > > >     If you fix this bug, this tag credits the report and lets us
> > > >     close it on our side:
> > > >
> > > > Reported-by: co+66c3f58096d0bde8@bugs.sh
> > > >
> > > >     Everything in this mail is validated by the reproducer below.
> > > >
> > > >     We also hold an unreviewed LLM-generated analysis and candidate
> > > >     patch. The same reproducer panics the unpatched kernel and runs
> > > >     clean with that patch applied. Use it as a starting point, or ignore
> > > >     it and write your own:
> > > >
> > > >         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
> > >
> > > Please just submit patches like normal, in a format that can be applied,
> > > and do not make us go to random links to attempt to get any information.
> > > That's not how kernel development works at all.
> > >
> >
> > Hi Greg,
> >
> > Sorry about this. We may have misunderstood your earlier reply in this thread:
> >
> > "But sure, posting bug reports is fine, but again, patches are better :)"
> >
> > https://lore.kernel.org/all/2026090139-shortlist-junkie-9bee@gregkh/#t
> >
> > We interpreted this as meaning that sending bug reports without
> > patches was acceptable. We understand your concern with the current
> > format, and we will stop sending reports in this format to you and
> > linux-usb@vger.kernel.org.
> >
> > To make sure we understand correctly and follow the appropriate
> > practice going forward, should we:
> >
> > 1. Send pure bug reports without any LLM-generated analysis or
> > candidate patch, similar to the bug reports syzbot sends to kernel
> > mailing lists;
> > 2. For USB, do not send bug reports and only submit patches in the
> > normal kernel format; or
> > 3. More generally, do not send bug reports to Linux kernel mailing
> > lists and only submit patches in the normal kernel format?
> >
> > Sorry again for the misunderstanding, and thanks for taking the time
> > to clarify this despite your busy schedule.
>
> Think about what _you_ would want to see if you were on the receiving
> end of hundreds of patches a week.  Would you want to see a vague email
> with links required to dig stuff out to potentially have to make up a
> fix yourself for an unknown and poorly worded description, or would you
> want a real patch, in mergable format, that describes the problem and
> how it is being resolved?
>
> I think the latter :)
>



> Right now, most developers just ignore syzbot reports, as we are
> drowning in real fixes from developers instead.  There's no need for us
> to go research new fixes when we are having a hard time keeping on top
> of the stuff people are sending us that are in mergable state already!
>

You are right. We understand how overloaded maintainers and reviewers
are right now.

It's true that bug reports without a mergeable patch still take
maintainers' attention, even when no response is expected.

We'd still like to make one last request: would it be okay to continue
sending a small number of reports to other lists, with no external
links (just PoC and crash sanitizer log)? We'd take responsibility for
each report and follow up with a patch, even if no one responds. We
just hope that contributors who know the subsystem better might be
interested in helping us check the issues.

We'll stop sending these reports to linux-usb@vger.kernel.org.
Super appreciate you taking the time to explain this and discuss it with us.

Thanks,
Xiang

> thanks,
>
> greg k-h

Re: [BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[Greg Kroah-Hartman]

On Mon, Sep 14, 2026 at 03:11:08PM -0700, Xiang Mei wrote:
> On Sun, Sep 13, 2026 at 2:19 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Sep 12, 2026 at 11:41:00AM -0700, Xiang Mei wrote:
> > > On Fri, Sep 11, 2026 at 10:47 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> > > > > This is a bug report, not a patch submission. See
> > > > > https://bugs.sh/reporting.html
> > > > >
> > > > > We found a bug reachable in:
> > > > >
> > > > >     path    drivers/usb/usbip
> > > > >     crash   NULL pointer dereference in stub_recv_cmd_submit()
> > > > >     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> > > > >
> > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > >
> > > > > == Notes ===============================================================
> > > > >     If you fix this bug, this tag credits the report and lets us
> > > > >     close it on our side:
> > > > >
> > > > > Reported-by: co+66c3f58096d0bde8@bugs.sh
> > > > >
> > > > >     Everything in this mail is validated by the reproducer below.
> > > > >
> > > > >     We also hold an unreviewed LLM-generated analysis and candidate
> > > > >     patch. The same reproducer panics the unpatched kernel and runs
> > > > >     clean with that patch applied. Use it as a starting point, or ignore
> > > > >     it and write your own:
> > > > >
> > > > >         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
> > > >
> > > > Please just submit patches like normal, in a format that can be applied,
> > > > and do not make us go to random links to attempt to get any information.
> > > > That's not how kernel development works at all.
> > > >
> > >
> > > Hi Greg,
> > >
> > > Sorry about this. We may have misunderstood your earlier reply in this thread:
> > >
> > > "But sure, posting bug reports is fine, but again, patches are better :)"
> > >
> > > https://lore.kernel.org/all/2026090139-shortlist-junkie-9bee@gregkh/#t
> > >
> > > We interpreted this as meaning that sending bug reports without
> > > patches was acceptable. We understand your concern with the current
> > > format, and we will stop sending reports in this format to you and
> > > linux-usb@vger.kernel.org.
> > >
> > > To make sure we understand correctly and follow the appropriate
> > > practice going forward, should we:
> > >
> > > 1. Send pure bug reports without any LLM-generated analysis or
> > > candidate patch, similar to the bug reports syzbot sends to kernel
> > > mailing lists;
> > > 2. For USB, do not send bug reports and only submit patches in the
> > > normal kernel format; or
> > > 3. More generally, do not send bug reports to Linux kernel mailing
> > > lists and only submit patches in the normal kernel format?
> > >
> > > Sorry again for the misunderstanding, and thanks for taking the time
> > > to clarify this despite your busy schedule.
> >
> > Think about what _you_ would want to see if you were on the receiving
> > end of hundreds of patches a week.  Would you want to see a vague email
> > with links required to dig stuff out to potentially have to make up a
> > fix yourself for an unknown and poorly worded description, or would you
> > want a real patch, in mergable format, that describes the problem and
> > how it is being resolved?
> >
> > I think the latter :)
> >
> 
> 
> 
> > Right now, most developers just ignore syzbot reports, as we are
> > drowning in real fixes from developers instead.  There's no need for us
> > to go research new fixes when we are having a hard time keeping on top
> > of the stuff people are sending us that are in mergable state already!
> >
> 
> You are right. We understand how overloaded maintainers and reviewers
> are right now.
> 
> It's true that bug reports without a mergeable patch still take
> maintainers' attention, even when no response is expected.
> 
> We'd still like to make one last request: would it be okay to continue
> sending a small number of reports to other lists, with no external
> links (just PoC and crash sanitizer log)? We'd take responsibility for
> each report and follow up with a patch, even if no one responds. We
> just hope that contributors who know the subsystem better might be
> interested in helping us check the issues.

Why not just send patches to resolve the issues?  That's the best thing
to work from, especially as you have ways to test if your patch is
correct or not.

thanks,

greg k-h

Re: [BUG] drivers/usb: NULL pointer dereference in stub_recv_cmd_submit()

[Xiang Mei]

On Mon, Sep 14, 2026 at 11:38 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Sep 14, 2026 at 03:11:08PM -0700, Xiang Mei wrote:
> > On Sun, Sep 13, 2026 at 2:19 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Sep 12, 2026 at 11:41:00AM -0700, Xiang Mei wrote:
> > > > On Fri, Sep 11, 2026 at 10:47 PM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Sat, Sep 12, 2026 at 02:06:13AM +0000, co wrote:
> > > > > > This is a bug report, not a patch submission. See
> > > > > > https://bugs.sh/reporting.html
> > > > > >
> > > > > > We found a bug reachable in:
> > > > > >
> > > > > >     path    drivers/usb/usbip
> > > > > >     crash   NULL pointer dereference in stub_recv_cmd_submit()
> > > > > >     commit  2f1baf1fc892 ("Merge tag 'trace-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
> > > > > >
> > > > > > Config, environment, the sanitizer report and a C reproducer follow.
> > > > > >
> > > > > > == Notes ===============================================================
> > > > > >     If you fix this bug, this tag credits the report and lets us
> > > > > >     close it on our side:
> > > > > >
> > > > > > Reported-by: co+66c3f58096d0bde8@bugs.sh
> > > > > >
> > > > > >     Everything in this mail is validated by the reproducer below.
> > > > > >
> > > > > >     We also hold an unreviewed LLM-generated analysis and candidate
> > > > > >     patch. The same reproducer panics the unpatched kernel and runs
> > > > > >     clean with that patch applied. Use it as a starting point, or ignore
> > > > > >     it and write your own:
> > > > > >
> > > > > >         patch.diff  https://bugs.sh/b/66c3f58096d0bde8/patch.diff
> > > > >
> > > > > Please just submit patches like normal, in a format that can be applied,
> > > > > and do not make us go to random links to attempt to get any information.
> > > > > That's not how kernel development works at all.
> > > > >
> > > >
> > > > Hi Greg,
> > > >
> > > > Sorry about this. We may have misunderstood your earlier reply in this thread:
> > > >
> > > > "But sure, posting bug reports is fine, but again, patches are better :)"
> > > >
> > > > https://lore.kernel.org/all/2026090139-shortlist-junkie-9bee@gregkh/#t
> > > >
> > > > We interpreted this as meaning that sending bug reports without
> > > > patches was acceptable. We understand your concern with the current
> > > > format, and we will stop sending reports in this format to you and
> > > > linux-usb@vger.kernel.org.
> > > >
> > > > To make sure we understand correctly and follow the appropriate
> > > > practice going forward, should we:
> > > >
> > > > 1. Send pure bug reports without any LLM-generated analysis or
> > > > candidate patch, similar to the bug reports syzbot sends to kernel
> > > > mailing lists;
> > > > 2. For USB, do not send bug reports and only submit patches in the
> > > > normal kernel format; or
> > > > 3. More generally, do not send bug reports to Linux kernel mailing
> > > > lists and only submit patches in the normal kernel format?
> > > >
> > > > Sorry again for the misunderstanding, and thanks for taking the time
> > > > to clarify this despite your busy schedule.
> > >
> > > Think about what _you_ would want to see if you were on the receiving
> > > end of hundreds of patches a week.  Would you want to see a vague email
> > > with links required to dig stuff out to potentially have to make up a
> > > fix yourself for an unknown and poorly worded description, or would you
> > > want a real patch, in mergable format, that describes the problem and
> > > how it is being resolved?
> > >
> > > I think the latter :)
> > >
> >
> >
> >
> > > Right now, most developers just ignore syzbot reports, as we are
> > > drowning in real fixes from developers instead.  There's no need for us
> > > to go research new fixes when we are having a hard time keeping on top
> > > of the stuff people are sending us that are in mergable state already!
> > >
> >
> > You are right. We understand how overloaded maintainers and reviewers
> > are right now.
> >
> > It's true that bug reports without a mergeable patch still take
> > maintainers' attention, even when no response is expected.
> >
> > We'd still like to make one last request: would it be okay to continue
> > sending a small number of reports to other lists, with no external
> > links (just PoC and crash sanitizer log)? We'd take responsibility for
> > each report and follow up with a patch, even if no one responds. We
> > just hope that contributors who know the subsystem better might be
> > interested in helping us check the issues.
>
> Why not just send patches to resolve the issues?  That's the best thing
> to work from, especially as you have ways to test if your patch is
> correct or not.
>

We appreciate your suggestions. We'll stop sending reports and instead
focus on working on patches.

Our original consideration was that reporting the bugs could help us
scale the patching effort. But you are right that maintainers
currently don't have the bandwidth to review these reports. We'll do
the right thing and move more slowly but make concrete contributions
by sending human-checked patches instead of reports.

Thanks again for your suggestions and for taking the time to discuss
this with us. It has been valuable talking with you.
Xiang

> thanks,
>
> greg k-h
>