linux-stable.git/drivers/usb/serial, branch v5.12.2 Linux kernel stable tree USB: serial: io_edgeport: fix memory leak in edge_startup 2021-03-09T08:05:37+00:00 Pavel Skripkin paskripkin@gmail.com 2021-03-01T23:01:52+00:00 cfdc67acc785e01a8719eeb7012709d245564701 sysbot found memory leak in edge_startup(). The problem was that when an error was received from the usb_submit_urb(), nothing was cleaned up. Reported-by: syzbot+59f777bdcbdd7eea5305@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Cc: stable@vger.kernel.org # 2.6.21: c5c0c55598ce Signed-off-by: Johan Hovold <johan@kernel.org> 
sysbot found memory leak in edge_startup().
The problem was that when an error was received from the usb_submit_urb(),
nothing was cleaned up.

Reported-by: syzbot+59f777bdcbdd7eea5305@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
Cc: stable@vger.kernel.org	# 2.6.21: c5c0c55598ce
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: ch341: add new Product ID 2021-03-09T08:05:36+00:00 Niv Sardi xaiki@evilgiggle.com 2021-03-01T20:16:12+00:00 5563b3b6420362c8a1f468ca04afe6d5f0a8d0a3 Add PID for CH340 that's found on cheap programmers. The driver works flawlessly as soon as the new PID (0x9986) is added to it. These look like ANU232MI but ship with a ch341 inside. They have no special identifiers (mine only has the string "DB9D20130716" printed on the PCB and nothing identifiable on the packaging. The merchant i bought it from doesn't sell these anymore). the lsusb -v output is: Bus 001 Device 009: ID 9986:7523 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x9986 idProduct 0x7523 bcdDevice 2.54 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 96mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Signed-off-by: Niv Sardi <xaiki@evilgiggle.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> 
Add PID for CH340 that's found on cheap programmers.

The driver works flawlessly as soon as the new PID (0x9986) is added to it.
These look like ANU232MI but ship with a ch341 inside. They have no special
identifiers (mine only has the string "DB9D20130716" printed on the PCB and
nothing identifiable on the packaging. The merchant i bought it from
doesn't sell these anymore).

the lsusb -v output is:
Bus 001 Device 009: ID 9986:7523
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x9986
  idProduct          0x7523
  bcdDevice            2.54
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               96mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      1
      bInterfaceProtocol      2
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1

Signed-off-by: Niv Sardi <xaiki@evilgiggle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: xr: fix NULL-deref on disconnect 2021-03-09T08:05:36+00:00 Johan Hovold johan@kernel.org 2021-02-26T10:08:26+00:00 f164f5d8a70245217bee89b246dc4fcfececa526 Claiming the sibling control interface is a bit more involved and specifically requires adding support to USB-serial core for managing either interface being unbound first, something which could otherwise lead to a NULL-pointer dereference. Similarly, additional infrastructure is also needed to handle suspend properly. Since the driver currently isn't actually using the control interface, we can defer this for now by simply not claiming the control interface. Fixes: c2d405aa86b4 ("USB: serial: add MaxLinear/Exar USB to Serial driver") Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Tested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> 
Claiming the sibling control interface is a bit more involved and
specifically requires adding support to USB-serial core for managing
either interface being unbound first, something which could otherwise
lead to a NULL-pointer dereference.

Similarly, additional infrastructure is also needed to handle suspend
properly.

Since the driver currently isn't actually using the control interface,
we can defer this for now by simply not claiming the control interface.

Fixes: c2d405aa86b4 ("USB: serial: add MaxLinear/Exar USB to Serial driver")
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: cp210x: add some more GE USB IDs 2021-03-09T08:05:36+00:00 Sebastian Reichel sebastian.reichel@collabora.com 2021-02-23T16:44:18+00:00 42213a0190b535093a604945db05a4225bf43885 GE CS1000 has some more custom USB IDs for CP2102N; add them to the driver to have working auto-probing. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> 
GE CS1000 has some more custom USB IDs for CP2102N; add them
to the driver to have working auto-probing.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: cp210x: add ID for Acuity Brands nLight Air Adapter 2021-03-09T08:05:36+00:00 Karan Singhal karan.singhal@acuitybrands.com 2021-02-16T16:03:10+00:00 ca667a33207daeaf9c62b106815728718def60ec IDs of nLight Air Adapter, Acuity Brands, Inc.: vid: 10c4 pid: 88d8 Signed-off-by: Karan Singhal <karan.singhal@acuitybrands.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> 
IDs of nLight Air Adapter, Acuity Brands, Inc.:
vid: 10c4
pid: 88d8

Signed-off-by: Karan Singhal <karan.singhal@acuitybrands.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
usb: Replace lkml.org links with lore 2021-02-11T12:50:46+00:00 Kees Cook keescook@chromium.org 2021-02-10T23:53:30+00:00 b9dd1962d9bf6c5247ba97a8b9e1689a10e22be1 As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org links with lore"), replace lkml.org links with lore to better use a single source that's more likely to stay available long-term. Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210210235330.3292719-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
links with lore"), replace lkml.org links with lore to better use a
single source that's more likely to stay available long-term.

Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210210235330.3292719-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'usb-serial-5.12-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next 2021-02-10T14:58:04+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2021-02-10T14:58:04+00:00 c85bfed171aaa91a32dcecd7962a4c880bf9d0ab Johan writes: USB-serial updates for 5.12-rc1 Here are the USB-serial updates for 5.12-rc1, including: - a line-speed fix for newer pl2303 devices - a line-speed fix for FTDI FT-X devices - a new xr_serial driver for MaxLinear/Exar devices (non-ACM mode) - a cdc-acm blacklist entry for when the xr_serial driver is enabled - cp210x support for software flow control - various cp210x modem-control fixes - an updated ZTE P685M modem entry to stop claiming the QMI interface - an update to drop the port_remove() driver-callback return value Included are also various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-5.12-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (41 commits) USB: serial: drop bogus to_usb_serial_port() checks USB: serial: make remove callback return void USB: serial: drop if with an always false condition USB: serial: option: update interface mapping for ZTE P685M USB: serial: ftdi_sio: restore divisor-encoding comments USB: serial: ftdi_sio: fix FTX sub-integer prescaler USB: serial: cp210x: clean up auto-RTS handling USB: serial: cp210x: fix RTS handling USB: serial: cp210x: clean up printk zero padding USB: serial: cp210x: clean up flow-control debug message USB: serial: cp210x: drop shift macros USB: serial: cp210x: fix modem-control handling USB: serial: cp210x: suppress modem-control errors USB: serial: mos7720: fix error code in mos7720_write() USB: serial: xr: fix B0 handling USB: serial: xr: fix pin configuration USB: serial: xr: fix gpio-mode handling USB: serial: xr: simplify line-speed logic USB: serial: xr: clean up line-settings handling USB: serial: xr: document vendor-request recipient ... 
Johan writes:

USB-serial updates for 5.12-rc1

Here are the USB-serial updates for 5.12-rc1, including:

 - a line-speed fix for newer pl2303 devices
 - a line-speed fix for FTDI FT-X devices
 - a new xr_serial driver for MaxLinear/Exar devices (non-ACM mode)
 - a cdc-acm blacklist entry for when the xr_serial driver is enabled
 - cp210x support for software flow control
 - various cp210x modem-control fixes
 - an updated ZTE P685M modem entry to stop claiming the QMI interface
 - an update to drop the port_remove() driver-callback return value

Included are also various clean ups.

All have been in linux-next with no reported issues.

* tag 'usb-serial-5.12-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (41 commits)
  USB: serial: drop bogus to_usb_serial_port() checks
  USB: serial: make remove callback return void
  USB: serial: drop if with an always false condition
  USB: serial: option: update interface mapping for ZTE P685M
  USB: serial: ftdi_sio: restore divisor-encoding comments
  USB: serial: ftdi_sio: fix FTX sub-integer prescaler
  USB: serial: cp210x: clean up auto-RTS handling
  USB: serial: cp210x: fix RTS handling
  USB: serial: cp210x: clean up printk zero padding
  USB: serial: cp210x: clean up flow-control debug message
  USB: serial: cp210x: drop shift macros
  USB: serial: cp210x: fix modem-control handling
  USB: serial: cp210x: suppress modem-control errors
  USB: serial: mos7720: fix error code in mos7720_write()
  USB: serial: xr: fix B0 handling
  USB: serial: xr: fix pin configuration
  USB: serial: xr: fix gpio-mode handling
  USB: serial: xr: simplify line-speed logic
  USB: serial: xr: clean up line-settings handling
  USB: serial: xr: document vendor-request recipient
  ...
USB: serial: drop bogus to_usb_serial_port() checks 2021-02-09T12:14:30+00:00 Johan Hovold johan@kernel.org 2021-02-08T15:48:06+00:00 1542d1324be1191d970f69c55e885af5dd810b84 The to_usb_serial_port() macro is implemented using container_of() so there's no need to check for NULL. Note that neither bus match() or probe() is ever called with a NULL struct device pointer so the checks weren't just misplaced. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Johan Hovold <johan@kernel.org> 
The to_usb_serial_port() macro is implemented using container_of() so
there's no need to check for NULL.

Note that neither bus match() or probe() is ever called with a NULL
struct device pointer so the checks weren't just misplaced.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: make remove callback return void 2021-02-09T12:13:58+00:00 Uwe Kleine-König uwe@kleine-koenig.org 2021-02-08T14:31:49+00:00 c5d1448fa353242635fa3e1fed6ab4558e0e7d9a All usb_serial drivers return 0 in their remove callbacks and driver core ignores the value returned by usb_serial_device_remove(). So change the remove callback to return void and return 0 unconditionally in usb_serial_device_remove(). Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210208143149.963644-2-uwe@kleine-koenig.org Signed-off-by: Johan Hovold <johan@kernel.org> 
All usb_serial drivers return 0 in their remove callbacks and driver
core ignores the value returned by usb_serial_device_remove(). So change
the remove callback to return void and return 0 unconditionally in
usb_serial_device_remove().

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210208143149.963644-2-uwe@kleine-koenig.org
Signed-off-by: Johan Hovold <johan@kernel.org>
USB: serial: drop if with an always false condition 2021-02-09T12:13:16+00:00 Uwe Kleine-König uwe@kleine-koenig.org 2021-02-08T14:31:48+00:00 a54af1b7d667927162d13083a8e2d470fb8722e2 In a bus remove function the passed device is always valid, so there is no need to check for it being NULL. (Side note: The check for port being non-NULL is broken anyhow, because to_usb_serial_port() is a wrapper around container_of() for a member that is not the first one. So port can hardly become NULL.) Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20210208143149.963644-1-uwe@kleine-koenig.org Signed-off-by: Johan Hovold <johan@kernel.org> 
In a bus remove function the passed device is always valid, so there is
no need to check for it being NULL.

(Side note: The check for port being non-NULL is broken anyhow, because
to_usb_serial_port() is a wrapper around container_of() for a member that is
not the first one. So port can hardly become NULL.)

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210208143149.963644-1-uwe@kleine-koenig.org
Signed-off-by: Johan Hovold <johan@kernel.org>