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
| ||
|
Message-ID: <1566378498.8347.6.camel@suse.com> Date: Wed, 21 Aug 2019 11:08:18 +0200 From: Oliver Neukum <oneukum@...e.com> To: Charles.Hyde@...lteam.com, linux-acpi@...r.kernel.org, linux-usb@...r.kernel.org Cc: Mario.Limonciello@...l.com, gregkh@...uxfoundation.org, nic_swsd@...ltek.com, netdev@...r.kernel.org Subject: Re: [RFC 1/4] Add usb_get_address and usb_set_address support Am Dienstag, den 20.08.2019, 22:18 +0000 schrieb Charles.Hyde@...lteam.com: > The core USB driver message.c is missing get/set address functionality This should go into usbnet. The CDC parser is where it is because it is needed for serial and network devices. As serial devices do not have a MAC, this can go into usbnet. > that stops ifconfig from being able to push MAC addresses out to USB > based ethernet devices. Without this functionality, some USB devices > stop responding to ethernet packets when using ifconfig to change MAC > addresses. This has been tested with a Dell Universal Dock D6000. > > Signed-off-by: Charles Hyde <charles.hyde@...lteam.com> > Cc: Mario Limonciello <mario.limonciello@...l.com> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> > Cc: linux-usb@...r.kernel.org > --- > drivers/usb/core/message.c | 59 ++++++++++++++++++++++++++++++++++++++ > include/linux/usb.h | 3 ++ > 2 files changed, 62 insertions(+) > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c > index 5adf489428aa..eea775234b09 100644 > --- a/drivers/usb/core/message.c > +++ b/drivers/usb/core/message.c > @@ -1085,6 +1085,65 @@ int usb_clear_halt(struct usb_device *dev, int pipe) > } > EXPORT_SYMBOL_GPL(usb_clear_halt); > > +/** > + * usb_get_address - > + * @dev: device whose endpoint is halted Which endpoint? > + * @mac: buffer for containing > + * Context: !in_interrupt () > + * > + * This will attempt to get the six byte MAC address from a USB device's > + * ethernet controller using GET_NET_ADDRESS command. > + * > + * This call is synchronous, and may not be used in an interrupt context. > + * > + * Return: Zero on success, or else the status code returned by the Well, I am afraid it will return 6 on success. > + * underlying usb_control_msg() call. > + */ > +int usb_get_address(struct usb_device *dev, unsigned char * mac) > +{ > + int ret = -ENOMEM; Initialization is unnecessary here. > + unsigned char *tbuf = kmalloc(256, GFP_NOIO); If you intentionally picked a safety margin of 42 times, this is cool. Otherwise it is a litttle much. > + > + if (!tbuf) > + return -ENOMEM; > + > + ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > + USB_CDC_GET_NET_ADDRESS, > + USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE, > + 0, USB_REQ_SET_ADDRESS, tbuf, 256, > + USB_CTRL_GET_TIMEOUT); > + if (ret == 6) > + memcpy(mac, tbuf, 6); You cannot ignore the case of devices sending more or less than 6 bytes. Regards Oliver
Powered by blists - more mailing lists