linux-stable.git/tools/usb, branch v4.19.136 Linux kernel stable tree usbip: Fix unsafe unaligned pointer usage 2020-02-24T07:34:45+00:00 Shuah Khan skhan@linuxfoundation.org 2020-01-09T01:24:16+00:00 b957a310c92b33d6a3ccb3cc43f6b48fb592324e [ Upstream commit 585c91f40d201bc564d4e76b83c05b3b5363fe7e ] Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool build fails with new gcc -Werror=address-of-packed-member checks. usbip_network.c: In function ‘usbip_net_pack_usb_device’: usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 79 | usbip_net_pack_uint32_t(pack, &udev->busnum); Fix with minor changes to pass by value instead of by address. Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 585c91f40d201bc564d4e76b83c05b3b5363fe7e ]

Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool
build fails with new gcc -Werror=address-of-packed-member checks.

usbip_network.c: In function ‘usbip_net_pack_usb_device’:
usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   79 |  usbip_net_pack_uint32_t(pack, &udev->busnum);

Fix with minor changes to pass by value instead of by address.

Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usbip: tools: fix fd leakage in the function of read_attr_usbip_status 2019-12-01T08:17:40+00:00 Hewenliang hewenliang4@huawei.com 2019-10-25T04:35:15+00:00 375b26a8648188957e2f3119c6cf078d3275bd74 commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream. We should close the fd before the return of read_attr_usbip_status. Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by: Hewenliang <hewenliang4@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream.

We should close the fd before the return of read_attr_usbip_status.

Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend")
Signed-off-by: Hewenliang <hewenliang4@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usbip: tools: fix atoi() on non-null terminated string 2019-12-01T08:16:38+00:00 Colin Ian King colin.king@canonical.com 2018-10-16T18:03:43+00:00 1f7f2a0666a31d824e98e54220bba96f5ac2f4ee [ Upstream commit e325808c0051b16729ffd472ff887c6cae5c6317 ] Currently the call to atoi is being passed a single char string that is not null terminated, so there is a potential read overrun along the stack when parsing for an integer value. Fix this by instead using a 2 char string that is initialized to all zeros to ensure that a 1 char read into the string is always terminated with a \0. Detected by cppcheck: "Invalid atoi() argument nr 1. A nul-terminated string is required." Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e325808c0051b16729ffd472ff887c6cae5c6317 ]

Currently the call to atoi is being passed a single char string
that is not null terminated, so there is a potential read overrun
along the stack when parsing for an integer value.  Fix this by
instead using a 2 char string that is initialized to all zeros
to ensure that a 1 char read into the string is always terminated
with a \0.

Detected by cppcheck:
"Invalid atoi() argument nr 1. A nul-terminated string is required."

Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usbip: tools: Fix read_usb_vudc_device() error path handling 2019-11-12T18:21:09+00:00 GwanYeong Kim gy741.kim@gmail.com 2019-10-18T03:22:23+00:00 e36be7959326f3b49653e64f46612ca6a5b98fd2 [ Upstream commit 28df0642abbf6d66908a2858922a7e4b21cdd8c2 ] This isn't really accurate right. fread() doesn't always return 0 in error. It could return < number of elements and set errno. Signed-off-by: GwanYeong Kim <gy741.kim@gmail.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20191018032223.4644-1-gy741.kim@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 28df0642abbf6d66908a2858922a7e4b21cdd8c2 ]

This isn't really accurate right. fread() doesn't always
return 0 in error. It could return < number of elements
and set errno.

Signed-off-by: GwanYeong Kim <gy741.kim@gmail.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20191018032223.4644-1-gy741.kim@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usbip: fix vhci_hcd controller counting 2019-04-20T07:16:01+00:00 Maciej Żenczykowski maze@google.com 2018-09-20T20:29:42+00:00 0d41c7b3860e5ab87d988ce20469485d0910d73a [ Upstream commit e0a2e73e501c77037c8756137e87b12c7c3c9793 ] Without this usbip fails on a machine with devices that lexicographically come after vhci_hcd. ie. $ ls -l /sys/devices/platform ... drwxr-xr-x. 4 root root 0 Sep 19 16:21 serial8250 -rw-r--r--. 1 root root 4096 Sep 19 23:50 uevent drwxr-xr-x. 6 root root 0 Sep 20 13:15 vhci_hcd.0 drwxr-xr-x. 4 root root 0 Sep 19 16:22 w83627hf.656 Because it detects 'w83627hf.656' as another vhci_hcd controller, and then fails to be able to talk to it. Note: this doesn't actually fix usbip's support for multiple controllers... that's still broken for other reasons ("vhci_hcd.0" is hardcoded in a string macro), but is enough to actually make it work on the above machine. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1631148 Cc: Jonathan Dieter <jdieter@gmail.com> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com> Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Tested-by: Jonathan Dieter <jdieter@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e0a2e73e501c77037c8756137e87b12c7c3c9793 ]

Without this usbip fails on a machine with devices
that lexicographically come after vhci_hcd.

ie.
  $ ls -l /sys/devices/platform
  ...
  drwxr-xr-x. 4 root root    0 Sep 19 16:21 serial8250
  -rw-r--r--. 1 root root 4096 Sep 19 23:50 uevent
  drwxr-xr-x. 6 root root    0 Sep 20 13:15 vhci_hcd.0
  drwxr-xr-x. 4 root root    0 Sep 19 16:22 w83627hf.656

Because it detects 'w83627hf.656' as another vhci_hcd controller,
and then fails to be able to talk to it.

Note: this doesn't actually fix usbip's support for multiple
controllers... that's still broken for other reasons
("vhci_hcd.0" is hardcoded in a string macro), but is enough to
actually make it work on the above machine.

See also:
  https://bugzilla.redhat.com/show_bug.cgi?id=1631148

Cc: Jonathan Dieter <jdieter@gmail.com>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Tested-by: Jonathan Dieter <jdieter@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools: usb: ffs-test: Fix build on big endian systems 2018-07-17T07:12:51+00:00 Peter Senna Tschudin peter.senna@gmail.com 2018-07-10T14:01:45+00:00 a2b22dddc7bb6110ac3b5ed1a60aa9279836fadb The tools/usb/ffs-test.c file defines cpu_to_le16/32 by using the C library htole16/32 function calls. However, cpu_to_le16/32 are used when initializing structures, i.e in a context where a function call is not allowed. It works fine on little endian systems because htole16/32 are defined by the C library as no-ops. But on big-endian systems, they are actually doing something, which might involve calling a function, causing build failures, such as: ffs-test.c:48:25: error: initializer element is not constant #define cpu_to_le32(x) htole32(x) ^~~~~~~ ffs-test.c:128:12: note: in expansion of macro ‘cpu_to_le32’ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2), ^~~~~~~~~~~ To solve this, we code cpu_to_le16/32 in a way that allows them to be used when initializing structures. This fix was imported from meta-openembedded/android-tools/fix-big-endian-build.patch written by Thomas Petazzoni <thomas.petazzoni@free-electrons.com>. CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> 
The tools/usb/ffs-test.c file defines cpu_to_le16/32 by using the C
library htole16/32 function calls. However, cpu_to_le16/32 are used when
initializing structures, i.e in a context where a function call is not
allowed.

It works fine on little endian systems because htole16/32 are defined by
the C library as no-ops. But on big-endian systems, they are actually
doing something, which might involve calling a function, causing build
failures, such as:

   ffs-test.c:48:25: error: initializer element is not constant
    #define cpu_to_le32(x)  htole32(x)
                            ^~~~~~~
   ffs-test.c:128:12: note: in expansion of macro ‘cpu_to_le32’
      .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
               ^~~~~~~~~~~

To solve this, we code cpu_to_le16/32 in a way that allows them to be
used when initializing structures. This fix was imported from
meta-openembedded/android-tools/fix-big-endian-build.patch written by
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>.

CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
usbip: usbip_detach: fix to check for invalid ports 2018-05-31T10:44:39+00:00 Shuah Khan (Samsung OSG) shuah@kernel.org 2018-05-30T03:03:08+00:00 40ecdeb1a1875f219fda1c17d4b40daa38aed5c7 usbip detach doesn't check for invalid ports and ports that are already detached. It attempts to remove state file(s) without validating the port and sends detach request to the driver for ports that are already detached. Add check for invalid ports (port > maxports) and ports that are already detached (status == VDEV_ST_NULL). Don't remove state files and don't send detach request for invalid ports and ports that are already detached. Add error and information messages that make sense. Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
usbip detach doesn't check for invalid ports and ports that are already
detached. It attempts to remove state file(s) without validating the port
and sends detach request to the driver for ports that are already detached.

Add check for invalid ports (port > maxports) and ports that are already
detached (status == VDEV_ST_NULL). Don't remove state files and don't send
detach request for invalid ports and ports that are already detached.

Add error and information messages that make sense.

Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usbip: usbip_detach: Fix memory, udev context and udev leak 2018-05-31T10:44:39+00:00 Shuah Khan (Samsung OSG) shuah@kernel.org 2018-05-29T22:13:03+00:00 d179f99a651685b19333360e6558110da2fe9bd7 detach_port() fails to call usbip_vhci_driver_close() from its error path after usbip_vhci_detach_device() returns failure, leaking memory allocated in usbip_vhci_driver_open() and holding udev_context and udev references. Fix it to call usbip_vhci_driver_close(). Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
detach_port() fails to call usbip_vhci_driver_close() from its error
path after usbip_vhci_detach_device() returns failure, leaking memory
allocated in usbip_vhci_driver_open() and holding udev_context and udev
references. Fix it to call usbip_vhci_driver_close().

Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usbip: dynamically allocate idev by nports found in sysfs 2018-05-31T10:43:14+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2018-05-25T14:23:46+00:00 de19ca6fd72c7dd45ad82403e7b3fe9c74ef6767 As the amount of available ports varies by the kernels build configuration. To remove the limitation of the fixed 128 ports we allocate the amount of idevs by using the number we get from the kernel. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
As the amount of available ports varies by the kernels build
configuration. To remove the limitation of the fixed 128 ports
we allocate the amount of idevs by using the number we get
from the kernel.

Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usbip: tools: usbipd: exclude exported devices from exportable device list 2018-03-22T12:08:20+00:00 Shuah Khan shuahkh@osg.samsung.com 2018-03-22T02:21:56+00:00 2699126bcf18db672451b82b26a1c8e954784fad usbipd includes exported devices in response to exportable device list. Exclude exported devices from exportable device list to avoid: - import requests for devices that are exported only to fail the request. - revealing devices that are imported by a client to another client. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
usbipd includes exported devices in response to exportable device list.
Exclude exported devices from exportable device list to avoid:

- import requests for devices that are exported only to fail the request.
- revealing devices that are imported by a client to another client.

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>