From: sashiko-bot@kernel.org
To: "Yehyeong Lee" <yhlee@isslab.korea.ac.kr>, linux-usb@vger.kernel.org
Cc: target-devel@vger.kernel.org
Subject: Re: [PATCH v2] usb: gadget: f_tcm: reject a short write data-out transfer
Date: Tue, 13 Oct 2026 01:26:19 +0000 [thread overview]
Message-ID: <sashiko-outbox-168835@kernel.org> (raw)
In-Reply-To: <20261013005854.2470384-1-yhlee@isslab.korea.ac.kr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: gadget: f_tcm: data_len not cleared on successful OUT transfer wedges pipe on backend failure
--
commit 63110d12dd83cfabcbf4574d13f034b5398b8e04
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
usb: gadget: f_tcm: reject a short write data-out transfer
This patch fails the command when a short write data-out occurs, clearing
cmd->data_len to prevent the BOT status phase from treating it as outstanding
WRITE data and queuing another OUT request.
> diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
> index 9e6d4f39900a2..cbe64f934724e 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1090,8 +1090,14 @@ static void usbg_data_write_cmpl(struct usb_ep *ep, struct usb_request *req)
> return;
> }
>
> - if (req->status) {
> - pr_err("%s() state %d transfer failed\n", __func__, cmd->state);
> + /* a short data-out left the buffer unwritten; don't commit stale data */
> + if (req->status || req->actual != req->length) {
> + struct usb_gadget *gadget = fuas_to_gadget(cmd->fu);
> +
> + /* the OUT data phase is over; nothing left for the status phase to drain */
> + cmd->data_len = 0;
> + dev_err_ratelimited(&gadget->dev, "%s() state %d transfer failed\n",
> + __func__, cmd->state);
> goto cleanup;
> }
[Severity: High]
Does cmd->data_len also need to be cleared for successful full OUT transfers?
If a full OUT transfer succeeds in usbg_data_write_cmpl() (req->status == 0
and req->actual == req->length), the request is submitted to the target core
backend. If the backend fails during execution (e.g., media error, ENOSPC) and
returns a check condition, usbg_send_status_response() routes to
bot_send_status() and subsequently to bot_send_bad_status().
Since cmd->data_len was not cleared, bot_send_bad_status() will attempt to
queue a drain OUT request:
drivers/usb/gadget/function/f_tcm.c:bot_send_bad_status() {
if (cmd->data_len) {
...
if (cmd->data_len > fu->ep_in->maxpacket) {
...
} else {
req->length = cmd->data_len;
cmd->data_len = 0;
}
...
usb_ep_queue(ep, req, GFP_KERNEL);
} else {
bot_enqueue_sense_code(fu, cmd);
}
}
However, the host has already finished sending all data during the data phase
and is waiting for the CSW on the IN endpoint. Queuing an OUT request here
will hang indefinitely, wedging the bulk pipe and causing a DoS for the
endpoint.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013005854.2470384-1-yhlee@isslab.korea.ac.kr?part=1
prev parent reply other threads:[~2026-10-13 1:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 0:58 [PATCH v2] usb: gadget: f_tcm: reject a short write data-out transfer Yehyeong Lee
2026-10-13 1:26 ` sashiko-bot [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=sashiko-outbox-168835@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=target-devel@vger.kernel.org \
--cc=yhlee@isslab.korea.ac.kr \
/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.