From: Shuah Khan <skhan@linuxfoundation.org>
To: Sung Byeongchan <tjdqudcks0424@naver.com>,
Valentina Manea <valentina.manea.m@gmail.com>,
Shuah Khan <shuah@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: vudc: snapshot endpoint state under lock
Date: Thu, 8 Oct 2026 01:01:31 -0600 [thread overview]
Message-ID: <52230f29-47ec-46a4-bd4b-5725af6654c1@linuxfoundation.org> (raw)
In-Reply-To: <20261007063054.26374-1-tjdqudcks0424@naver.com>
On 10/7/26 00:30, Sung Byeongchan wrote:
> v_recv_cmd_submit() finds an endpoint and records its type while holding
> udc->lock, but then drops the lock and rereads both ep->type and ep->desc.
> The VUDC timer drops this lock around gadget setup callbacks, and
> endpoint disable clears ep->desc under the lock. A USB/IP host can
> therefore race an ISO CMD_SUBMIT with endpoint disable and make
> usb_endpoint_maxp() dereference NULL.
>
> Copy the endpoint type and derived isochronous maximum packet size while
> the lock still protects the descriptor. Use the snapshots for
> validation, URB allocation, and pipe setup after unlocking.
>
> This was found by source review with AI assistance. The production VUDC
> and UAC2 fixture panicked in two independent boots without a diagnostic
> kernel change. The fixed kernel completed 5,257 race attempts without
> an oops or panic and preserved the normal and serialized controls.
This change is incorrect to fix the problem you are describing. Can you
elaborate on how your testing method and environment in more detail?
thanks,
-- Shuah
prev parent reply other threads:[~2026-10-08 7:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 6:30 [PATCH] usbip: vudc: snapshot endpoint state under lock Sung Byeongchan
2026-10-07 6:46 ` sashiko-bot
2026-10-08 7:01 ` Shuah Khan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52230f29-47ec-46a4-bd4b-5725af6654c1@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=tjdqudcks0424@naver.com \
--cc=valentina.manea.m@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox