[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190820222805.GD8120@kroah.com>
Date: Tue, 20 Aug 2019 15:28:05 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Charles.Hyde@...lteam.com
Cc: linux-usb@...r.kernel.org, linux-acpi@...r.kernel.org,
Mario.Limonciello@...l.com, oliver@...kum.org,
netdev@...r.kernel.org, nic_swsd@...ltek.com
Subject: Re: [RFC 1/4] Add usb_get_address and usb_set_address support
On Tue, Aug 20, 2019 at 10:18:42PM +0000, Charles.Hyde@...lteam.com wrote:
> +int usb_get_address(struct usb_device *dev, unsigned char * mac)
> +{
> + int ret = -ENOMEM;
> + unsigned char *tbuf = kmalloc(256, GFP_NOIO);
On a technical level, why are you asking for 256 bytes here, and in the
control message, yet assuming you will only get 6 back for a correct
message? Shouldn't you be only asking for 6 bytes?
> +
> + 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);
> +
> + kfree(tbuf);
> + return ret;
So if 100 is returned by the device (not likely, but let's say 7), then
you return 7 bytes, yet you did not copy the data into the pointer given
to you.
SHouldn't you report a real error for when this happens (hint, it will.)
thanks,
greg k-h
Powered by blists - more mailing lists