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: <87h9c5638l.fsf@nemi.mork.no>
Date:	Mon, 04 Jul 2016 13:40:10 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	netdev@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH net,stable] cdc_ncm: workaround for EM7455 "silent" data interface

Oliver Neukum <oneukum@...e.com> writes:
> On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote:
>> Several Lenovo users have reported problems with their Sierra
>> Wireless EM7455 modem. The driver has loaded successfully and
>> the MBIM management channel has appeared to work, including
>> establishing a connection to the mobile network. But no frames
>> have been received over the data interface.
>
> If this is needed in open() it must also be needed in reset_resume()

reset_resume needs fixing in general. This is completely unrelated to
this bug. In fact, as we don't do any NCM control messages there in the
current resume, I'm not sure this firmware bug is triggered by it.  But
it's untestable, because:

reset_resume cannot work for MBIM. At least not with the driver/userspace
model we have chosen.  The driver does not have enough information about
the device state to recreate it.  It could maybe work for NCM, but I
don't think it currently does.  The NCM protocol requires some minimum
driver and device negotiation, and the current NCM .reset_resume points
to usbnet_resume which completely ignores that.

Proposals for fixing reset_resume would of course be good, and I'll
think about how to deal with it, but I don't think it should block
fixing the current issue.  They are not related.


Bjørn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ