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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 1 May 2022 21:15:55 +0300
From:   Sergey Ryazanov <ryazanov.s.a@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Oliver Neukum <oneukum@...e.com>, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] usb: cdc-wdm: fix reading stuck on device close

On Sun, May 1, 2022 at 9:09 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Sun, May 01, 2022 at 08:58:28PM +0300, Sergey Ryazanov wrote:
>> cdc-wdm tracks whether a response reading request is in-progress and
>> blocks the next request from being sent until the previous request is
>> completed. As soon as last user closes the cdc-wdm device file, the
>> driver cancels any ongoing requests, resets the pending response
>> counter, but leaves the response reading in-progress flag
>> (WDM_RESPONDING) untouched.
>>
>> So if the user closes the device file during the response receive
>> request is being performed, no more data will be obtained from the
>> modem. The request will be cancelled, effectively preventing the
>> WDM_RESPONDING flag from being reseted. Keeping the flag set will
>> prevent a new response receive request from being sent, permanently
>> blocking the read path. The read path will staying blocked until the
>> module will be reloaded or till the modem will be re-attached.
>>
>> This stuck has been observed with a Huawei E3372 modem attached to an
>> OpenWrt router and using the comgt utility to set up a network
>> connection.
>>
>> Fix this issue by clearing the WDM_RESPONDING flag on the device file
>> close.
>>
>> Without this fix, the device reading stuck can be easily reproduced in a
>> few connection establishing attempts. With this fix, a load test for
>> modem connection re-establishing worked for several hours without any
>> issues.
>>
>> Fixes: 922a5eadd5a3 ("usb: cdc-wdm: Fix race between autosuspend and
>> reading from the device")
>
> Nit, Fixes: lines should only be one line, I'll fix this up when
> applying it.

Ouch. Sorry.

>> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@...il.com>
>> ---
>>
>> Technically, cdc-wdm belongs to the USB subsystem even though it serves
>> WWAN devices. I think this fix should be applied (backported) to LTS
>> versions too. So I targeted it to the 'net' tree, but send it to both
>> lists to get a feedback. Greg, Jakub, what is the best tree for this
>> fix?
>>
>> ---
>>  drivers/usb/class/cdc-wdm.c | 1 +
>>  1 file changed, 1 insertion(+)
>
> scripts/get_maintainer.pl is pretty clear this goes through the USB
> tree.  I'll queue it up in a few days, thanks,

Thank you for your clarification, will keep in mind.

-- 
Sergey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ