linux-kernel - Re: [PATCH v3] usb: gadget: eem: fix echo command packet response issue

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] [day] [month] [year] [list]

Message-ID: <5b55b8b8649cbe9049e088cdd7b0d24f@codeaurora.org>
Date:   Fri, 18 Jun 2021 09:19:16 +0800
From:   linyyuan@...eaurora.org
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Felipe Balbi <balbi@...nel.org>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, Linyu Yuan <linyyuan@...eaurora.com>
Subject: Re: [PATCH v3] usb: gadget: eem: fix echo command packet response
 issue

On 2021-06-17 21:22, Greg Kroah-Hartman wrote:
> On Wed, Jun 16, 2021 at 07:51:42PM +0800, Linyu Yuan wrote:
>> From: Linyu Yuan <linyyuan@...eaurora.com>
>> 
>> when receive eem echo command, it will send a response,
>> but queue this response to the usb request which allocate
>> from gadget device endpoint zero,
>> and transmit the request to IN endpoint of eem interface.
>> 
>> on dwc3 gadget, it will trigger following warning in function
>> __dwc3_gadget_ep_queue(),
>> 
>> 	if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
>> 				&req->request, req->dep->name))
>> 		return -EINVAL;
> 
> Is this really a problem?  I am guessing the request will not work at
> all?  Or just warn and continue with it?
yes, it is a real problem of f_eem driver which request from it will 
queue fail,
which means following error happen.
       if (usb_ep_queue(port->in_ep, req, GFP_ATOMIC))
		DBG(cdev, "echo response queue fail\n");
> 
> How was this ever working?
i think for eem link command packet, normally we will never seen it if 
both side arelinux system.
as eem driver will add data header and send it to peer.

only it is eem driver bug which read network data as link command packet 
(this issue fixed in my last change).
> 
>> 
>> fix it by allocating a usb request from IN endpoint of eem interface,
>> and transmit the usb request to same IN endpoint of eem interface.
>> 
>> Signed-off-by: Linyu Yuan <linyyuan@...eaurora.com>
>> ---
> 
> What commit does this fix?  Should it be backported to older stable
> kernels?  If so, how far back?
yes, we can backport to all active LTS kernel.
> 
> thanks,
> 
> greg k-h