From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: me@samcday.com
Cc: Valentina Manea <valentina.manea.m@gmail.com>,
Shuah Khan <shuah@kernel.org>, Hongren Zheng <i@zenithal.me>,
Krzysztof Opasiak <k.opasiak@samsung.com>,
Igor Kotrasinski <i.kotrasinsk@samsung.com>,
Karol Kosik <karo9@interia.eu>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] usbip: vudc: fix NULL deref in vep_dequeue()
Date: Thu, 25 Jun 2026 16:12:38 +0100 [thread overview]
Message-ID: <2026062518-treason-styling-5185@gregkh> (raw)
In-Reply-To: <20260620-usbip-vudc-deque-fix-v2-1-d1913ab4611b@samcday.com>
On Sat, Jun 20, 2026 at 10:18:09AM +1000, Sam Day via B4 Relay wrote:
> From: Sam Day <me@samcday.com>
>
> vep_alloc_request() wasn't initializing vrequest->udc, so cancellations
> on the FunctionFS AIO path were arriving in vep_dequeue without a valid
> UDC reference.
>
> Since vrequest->udc is never actually properly used anywhere, we opt to
> remove it, and update vep_dequeue to obtain a reference to the udc with
> ep_to_vudc(), consistent with the other vep_ ops.
>
> AFAICT this bug has existed for ~10 years. Seems that nobody has really
> stressed the FunctionFS AIO path on usbip's vudc.
>
> I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints
> via AIO. Before the fix, running `usbip attach` from the host would
> cause the guest to oops with the following backtrace:
>
> Call trace:
> vep_dequeue+0x1c/0xe4 (P)
> usb_ep_dequeue+0x14/0x20
> ffs_aio_cancel+0x24/0x34
> __arm64_sys_io_cancel+0xb0/0x124
> do_el0_svc+0x68/0x100
> el0_svc+0x18/0x5c
> el0t_64_sync_handler+0x98/0xdc
> el0t_64_sync+0x154/0x158
>
> Assisted-by: opencode:openai/gpt-5.5
> Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops")
> Signed-off-by: Sam Day <me@samcday.com>
> ---
> Changes in v2:
> - Reworked to remove vrequest->udc entirely and a call to ep_to_vudc()
> from vep_deqe
> - Link to v1: https://lore.kernel.org/r/20260619-usbip-vudc-deque-fix-v1-1-9021463b1903@samcday.com
> ---
> drivers/usb/usbip/vudc.h | 1 -
> drivers/usb/usbip/vudc_dev.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/usbip/vudc.h b/drivers/usb/usbip/vudc.h
> index faf61c9c6a98..5ef0e7d9b23a 100644
> --- a/drivers/usb/usbip/vudc.h
> +++ b/drivers/usb/usbip/vudc.h
> @@ -38,7 +38,6 @@ struct vep {
>
> struct vrequest {
> struct usb_request req;
> - struct vudc *udc;
> struct list_head req_entry; /* Request queue */
> };
>
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index c5f079c5a1ea..f0a1a44c18e3 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -344,7 +344,7 @@ static int vep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
>
> ep = to_vep(_ep);
> req = to_vrequest(_req);
> - udc = req->udc;
> + udc = ep_to_vudc(ep);
Why is "req" still needed now? Shouldn't that variable be removed also?
thanks,
greg k-h
prev parent reply other threads:[~2026-06-25 15:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260620001816eucas1p216d49bf6a91cb50717b1bb9e1420d0d6@eucas1p2.samsung.com>
2026-06-20 0:18 ` [PATCH v2] usbip: vudc: fix NULL deref in vep_dequeue() Sam Day
2026-06-20 0:18 ` Sam Day via B4 Relay
2026-06-22 7:36 ` Igor Kotrasinski/Security (PLT) /SRPOL/Engineer/Samsung Electronics
2026-06-25 15:12 ` Greg Kroah-Hartman [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=2026062518-treason-styling-5185@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=i.kotrasinsk@samsung.com \
--cc=i@zenithal.me \
--cc=k.opasiak@samsung.com \
--cc=karo9@interia.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=me@samcday.com \
--cc=shuah@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.