linux-kernel - Re: [PATCH] usb: dwc3: gadget: Fix failure to detect end of transfer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191230185703.GA1763367@kroah.com>
Date:   Mon, 30 Dec 2019 19:57:03 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     balbi@...nel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: dwc3: gadget: Fix failure to detect end of transfer

On Mon, Dec 30, 2019 at 04:13:21PM +0000, Bryan O'Donoghue wrote:
> A recent bugfix 8c7d4b7b3d43 ("usb: dwc3: gadget: Fix logical condition")
> correctly fixes a logical error in the gadget driver but, exposes a further
> bug in determining when a transfer has completed.
> 
> Prior to 8c7d4b7b3d43 we were calling dwc3_gadget_giveback() when we
> shouldn't have been. Afer this change the below test fails to complete on
> my hardware.
> 
> Host:
> echo "host" > /dev/ttyACM0
> 
> Device:
> cat < /dev/ttyGS0
> 
> This is caused by the driver incorrectly detecting end of transfer, a
> problem that had previous been masked by the continuous calling of
> dwc3_gadget_giveback() prior to 8c7d4b7b3d43.
> 
> Remediate by making the test <= instead of ==
> 
> Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling")
> 
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> ---
>  drivers/usb/dwc3/gadget.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I think this patch:
	https://lore.kernel.org/linux-usb/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.com/

should fix this issue instead, right?

If not, do I need to include both of these?

thanks,

greg k-h