linux-kernel - Re: [PATCH 1/1] usb: misc: usbtest: add fix for driver hang

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: <57AAB78F.8030203@linux.intel.com>
Date:	Wed, 10 Aug 2016 13:11:43 +0800
From:	Lu Baolu <baolu.lu@...ux.intel.com>
To:	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/1] usb: misc: usbtest: add fix for driver hang

Hi,

On 08/09/2016 10:18 PM, Alan Stern wrote:
> On Tue, 9 Aug 2016, Felipe Balbi wrote:
>
>> Hi,
>>
>> Lu Baolu <baolu.lu@...ux.intel.com> writes:
>>> In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
>>> into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
>>> directly if req->status has been set to a non-zero value. This will
>>> cause driver hang as soon as transfer time out is triggered.
> ...
>
>>> This patch fixes this driver hang. It should be back-ported to stable
>>> kernel with version after v3.15.
>>>
>>> Cc: stable@...r.kernel.org
>>> Cc: Alan Stern <stern@...land.harvard.edu>
>>> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
>>> ---
>>>  drivers/usb/misc/usbtest.c | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
>>> index 6b978f0..6c6586d 100644
>>> --- a/drivers/usb/misc/usbtest.c
>>> +++ b/drivers/usb/misc/usbtest.c
>>> @@ -585,7 +585,6 @@ static void sg_timeout(unsigned long _req)
>>>  {
>>>  	struct usb_sg_request	*req = (struct usb_sg_request *) _req;
>>>  
>>> -	req->status = -ETIMEDOUT;
>>>  	usb_sg_cancel(req);
>>>  }
>> IMO, req->status = -ETIMEDOUT should still be done, but perhaps after
>> usb_sg_cancel(). Alan?
> That would race with sg_complete(), perhaps causing a bunch of error
> messages.  A better approach would be to delete the assignment as
> above and then change perform_sglist():
>
>  		usb_sg_wait(req);
> -		del_timer_sync(&sg_timer);
>  		retval = req->status;
> +		if (!del_timer_sync(&sg_timer))
> +			retval = -ETIMEDOUT;

I agree. I will send v2 with this change included.

I am afraid that req->status is managed by usb core. A spin lock
is used to serialize the change of it. The driver could check the
value of req->status, but should not change it (especially change
it without the hold of the lock). Otherwise, it could cause race or
errors in usb core.

This happens in another driver implemented in drivers/mfd/rtsx_usb.c.

static void rtsx_usb_sg_timed_out(unsigned long data)
{
        struct rtsx_ucr *ucr = (struct rtsx_ucr *)data;

        dev_dbg(&ucr->pusb_intf->dev, "%s: sg transfer timed out", __func__);
        usb_sg_cancel(&ucr->current_sg);

        /* we know the cancellation is caused by time-out */
        ucr->current_sg.status = -ETIMEDOUT;
                                   (^^^^ status being changed by driver without hold of lock)
}

I will send another patch to enhance this later.

Best regards,
Lu Baolu