netdev - Re: [PATCH] cdc-ether: clean packet filter upon probe

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: <87d2c2xm2k.fsf@nemi.mork.no>
Date:	Fri, 15 Aug 2014 09:13:07 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] cdc-ether: clean packet filter upon probe

Oliver Neukum <oneukum@...e.de> writes:

> On Thu, 2014-08-14 at 13:11 +0200, Bjørn Mork wrote:
>> Oliver Neukum <oneukum@...e.de> writes:
>> 
>> > There are devices that don't do reset all the way. So the packet filter should
>> > be set to a sane initial value. Failure to do so leads to intermittent failures
>> > of DHCP on some systems under some conditions.
>> >
>> > Signed-off-by: Oliver Neukum <oneukum@...e.de>
>> > ---
>> >  drivers/net/usb/cdc_ether.c | 16 ++++++++++++++++
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
>> > index 9ea4bfe..2a32d91 100644
>> > --- a/drivers/net/usb/cdc_ether.c
>> > +++ b/drivers/net/usb/cdc_ether.c
>> > @@ -341,6 +341,22 @@ next_desc:
>> >  		usb_driver_release_interface(driver, info->data);
>> >  		return -ENODEV;
>> >  	}
>> > +
>> > +	/* Some devices don't initialise properly. In particular
>> > +	 * the packet filter is not reset. There are devices that
>> > +	 * don't do reset all the way. So the packet filter should
>> > +	 * be set to a sane initial value.
>> > +	 */
>> > +	usb_control_msg(dev->udev,
>> > +			usb_sndctrlpipe(dev->udev, 0),
>> > +			USB_CDC_SET_ETHERNET_PACKET_FILTER,
>> > +			USB_TYPE_CLASS | USB_RECIP_INTERFACE,
>> > +			USB_CDC_PACKET_TYPE_ALL_MULTICAST | USB_CDC_PACKET_TYPE_DIRECTED | USB_CDC_PACKET_TYPE_BROADCAST,
>> > +			intf->cur_altsetting->desc.bInterfaceNumber,
>> > +			NULL,
>> > +			0,
>> > +			USB_CTRL_SET_TIMEOUT
>> > +		);
>> >  	return 0;
>> >  
>> >  bad_desc:
>> 
>> Hmm, the usbnet_generic_cdc_bind() function is used by the vendor
>> specific zaurus and rndis_host drivers as well.  Are we sure the
>> USB_CDC_SET_ETHERNET_PACKET_FILTER message is supported by all devices
>> supported by these drivers?
>
> Support for this request is mandatory.

Yes, there is no problem for standard conforming ECM devices.  I fully
agree there. 

But standard conformance is unfortunately not something we can expect.
My question was regarding the non-conforming devices, like the ones
supported by th zaurus and rndis_host drivers.  These drivers are made
solely because the supported devices do *not* conform to the ECM spec.
If you know they support the request, then fine.  But I do not think we
can assume that they do without testing it, despite what the ECM spec
says.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html