Re: [PATCH] usb: gadget: dummy_hcd: fix data corruption with queued requests

[Sebastian Urban]

On 3/15/26 15:44, Alan Stern wrote:
> On Sun, Mar 15, 2026 at 10:03:07AM +0100, Sebastian Urban wrote:
>> The transfer() function in dummy_hcd iterates over all queued gadget
>> requests for a given endpoint via list_for_each_entry(). When the
>> per-frame bandwidth budget is exhausted mid-request, leaving a
>> partially-transferred gadget request, the loop continues to the next
>> queued request instead of stopping.
> 
> Why do you say this?  Did you not see the code (at line 1445
> approximately):
> 
> 		if (unlikely(len == 0))
> 			is_short = 1;
> 		else {
> 			/* not enough bandwidth left? */
> 			if (limit < ep->ep.maxpacket && limit < len)
> 				break;
> 
> It does break out of the loop when there is not enough space remaining
> in the bandwidth budget for another transaction.  But it does so at the
> start of the iteration following the last allowed transfer, rather than
> at the end of last transfer's iteration (as your patch does).
> 
You're right that the existing bandwidth check at line 1444 handles the 
general case of a non-zero request following a partial transfer.

However, if a ZLP follows a partially-transferred request, the check is 
skipped because of the unlikely(len == 0) branch, leading to a false 
complete of the transfer with a shortened length.

Thus the bug can only be triggered by a ZLP. I will resubmit the patch 
with an updated commit message.