1. 02 7月, 2019 1 次提交
  2. 25 6月, 2019 1 次提交
    • B
      qmi_wwan: Fix out-of-bounds read · 904d88d7
      Bjørn Mork 提交于
      The syzbot reported
      
       Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x67/0x231 mm/kasan/report.c:188
        __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
        kasan_report+0xe/0x20 mm/kasan/common.c:614
        qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x660 drivers/base/dd.c:509
        driver_probe_device+0x104/0x210 drivers/base/dd.c:670
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
      
      Caused by too many confusing indirections and casts.
      id->driver_info is a pointer stored in a long.  We want the
      pointer here, not the address of it.
      
      Thanks-to: Hillf Danton <hdanton@sina.com>
      Reported-by: syzbot+b68605d7fadd21510de1@syzkaller.appspotmail.com
      Cc: Kristian Evensen <kristian.evensen@gmail.com>
      Fixes: e4bf6348 ("qmi_wwan: Add quirk for Quectel dynamic config")
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      904d88d7
  3. 19 6月, 2019 1 次提交
  4. 15 6月, 2019 4 次提交
  5. 05 6月, 2019 2 次提交
  6. 31 5月, 2019 1 次提交
  7. 22 5月, 2019 2 次提交
    • K
      usbnet: fix kernel crash after disconnect · ad70411a
      Kloetzke Jan 提交于
      When disconnecting cdc_ncm the kernel sporadically crashes shortly
      after the disconnect:
      
        [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
        ...
        [   58.006653] PC is at 0x0
        [   58.009202] LR is at call_timer_fn+0xec/0x1b4
        [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
        [   58.020976] sp : ffffff8008003da0
        [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
        [   58.029618] x27: 000000000000000a x26: 0000000000000100
        [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
        [   58.040263] x23: 0000000000000000 x22: 0000000000000000
        [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
        [   58.050910] x19: 0000000000000100 x18: 0000000000000000
        [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
        [   58.061556] x15: 0000000000000001 x14: 000000000000006e
        [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
        [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
        [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
        [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
        [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
        [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
        [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
        ...
        [   58.205800] [<          (null)>]           (null)
        [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
        [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
        [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
        [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
        [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
        [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
        ...
      
      The crash happens roughly 125..130ms after the disconnect. This
      correlates with the 'delay' timer that is started on certain USB tx/rx
      errors in the URB completion handler.
      
      The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
      usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
      flight. This only makes sense if no new URBs are submitted
      concurrently, though. But the usbnet_start_xmit() can run at the same
      time on another CPU which almost unconditionally submits an URB. The
      error callback of the new URB will then schedule the timer after it was
      already stopped.
      
      The fix adds a check if the tx queue is stopped after the tx list lock
      has been taken. This should reliably prevent the submission of new URBs
      while usbnet_terminate_urbs() does its job. The same thing is done on
      the rx side even though it might be safe due to other flags that are
      checked there.
      Signed-off-by: NJan Klötzke <Jan.Kloetzke@preh.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad70411a
    • B
      usbnet: ipheth: fix racing condition · 94d250fa
      Bernd Eckstein 提交于
      Fix a racing condition in ipheth.c that can lead to slow performance.
      
      Bug: In ipheth_tx(), netif_wake_queue() may be called on the callback
      ipheth_sndbulk_callback(), _before_ netif_stop_queue() is called.
      When this happens, the queue is stopped longer than it needs to be,
      thus reducing network performance.
      
      Fix: Move netif_stop_queue() in front of usb_submit_urb(). Now the order
      is always correct. In case, usb_submit_urb() fails, the queue is woken up
      again as callback will not fire.
      
      Testing: This racing condition is usually not noticeable, as it has to
      occur very frequently to slowdown the network. The callback from the USB
      is usually triggered slow enough, so the situation does not appear.
      However, on a Ubuntu Linux on VMWare Workstation, running on Windows 10,
      the we loose the race quite often and the following speedup can be noticed:
      
      Without this patch: Download:  4.10 Mbit/s, Upload:  4.01 Mbit/s
      With this patch:    Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
      Signed-off-by: NOliver Zweigle <Oliver.Zweigle@faro.com>
      Signed-off-by: NBernd Eckstein <3ernd.Eckstein@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94d250fa
  8. 21 5月, 2019 3 次提交
  9. 17 5月, 2019 4 次提交
  10. 10 5月, 2019 3 次提交
  11. 08 5月, 2019 1 次提交
    • P
      net: usb: smsc: fix warning reported by kbuild test robot · 5503a688
      Petr Štetiar 提交于
      This patch fixes following warning reported by kbuild test robot:
      
       In function ‘memcpy’,
           inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
           inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
       ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
         return __builtin_memcpy(p, q, size);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
       drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
       ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’
      
      I've replaced the offending memcpy with ether_addr_copy, because I'm
      100% sure, that of_get_mac_address can't return NULL as it returns valid
      pointer or ERR_PTR encoded value, nothing else.
      
      I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
      would make the warning disappear also, but it would be confusing to
      check for impossible return value just to make a compiler happy.
      
      Fixes: adfb3cb2 ("net: usb: support of_get_mac_address new ERR_PTR error")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Reviewed-by: NWoojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5503a688
  12. 06 5月, 2019 1 次提交
  13. 04 5月, 2019 1 次提交
  14. 26 4月, 2019 2 次提交
    • G
      usbnet: ipheth: Simplify device detection · f7abc061
      Guenter Roeck 提交于
      All Apple products use the same protocol for tethering over USB.
      To simplify the code and make it future proof, use
      USB_VENDOR_AND_INTERFACE_INFO() instead of
      USB_DEVICE_AND_INTERFACE_INFO() to automatically detect and support
      all existing and future Apple products using the same interface.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7abc061
    • B
      qmi_wwan: new Wistron, ZTE and D-Link devices · 88ef66a2
      Bjørn Mork 提交于
      Adding device entries found in vendor modified versions of this
      driver.  Function maps for some of the devices follow:
      
      WNC D16Q1, D16Q5, D18Q1 LTE CAT3 module (1435:0918)
      
      MI_00 Qualcomm HS-USB Diagnostics
      MI_01 Android Debug interface
      MI_02 Qualcomm HS-USB Modem
      MI_03 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_04 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_05 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_06 USB Mass Storage Device
      
       T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
       D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
       P:  Vendor=1435 ProdID=0918 Rev= 2.32
       S:  Manufacturer=Android
       S:  Product=Android
       S:  SerialNumber=0123456789ABCDEF
       C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
       I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
       E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
       E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
       E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
       E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
       E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      
      WNC D18 LTE CAT3 module (1435:d182)
      
      MI_00 Qualcomm HS-USB Diagnostics
      MI_01 Androd Debug interface
      MI_02 Qualcomm HS-USB Modem
      MI_03 Qualcomm HS-USB NMEA
      MI_04 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_05 Qualcomm Wireless HS-USB Ethernet Adapter
      MI_06 USB Mass Storage Device
      
      ZM8510/ZM8620/ME3960 (19d2:0396)
      
      MI_00 ZTE Mobile Broadband Diagnostics Port
      MI_01 ZTE Mobile Broadband AT Port
      MI_02 ZTE Mobile Broadband Modem
      MI_03 ZTE Mobile Broadband NDIS Port (qmi_wwan)
      MI_04 ZTE Mobile Broadband ADB Port
      
      ME3620_X (19d2:1432)
      
      MI_00 ZTE Diagnostics Device
      MI_01 ZTE UI AT Interface
      MI_02 ZTE Modem Device
      MI_03 ZTE Mobile Broadband Network Adapter
      MI_04 ZTE Composite ADB Interface
      Reported-by: NLars Melin <larsm17@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88ef66a2
  15. 23 4月, 2019 1 次提交
  16. 09 4月, 2019 1 次提交
    • K
      qmi_wwan: Add quirk for Quectel dynamic config · e4bf6348
      Kristian Evensen 提交于
      Most, if not all, Quectel devices use dynamic interface numbers, and
      users are able to change the USB configuration at will. Matching on for
      example interface number is therefore not possible.
      
      Instead, the QMI device can be identified by looking at the interface
      class, subclass and protocol (all 0xff), as well as the number of
      endpoints. The reason we need to look at the number of endpoints, is
      that the diagnostic port interface has the same class, subclass and
      protocol as QMI. However, the diagnostic port only has two endpoints,
      while QMI has three.
      
      Until now, we have identified the QMI device by combining a match on
      class, subclass and protocol, with a call to the function
      quectel_diag_detect(). In quectel_diag_detect(), we check if the number
      of endpoints matches for known Quectel vendor/product ids.
      
      Adding new vendor/product ids to quectel_diag_detect() is not a good
      long-term solution. This commit replaces the function with a quirk, and
      applies the quirk to affected Quectel devices that I have been able to
      test the change with (EP06, EM12 and EC25). If the quirk is set and the
      number of endpoints equal two, we return from qmi_wwan_probe() with
      -ENODEV.
      Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4bf6348
  17. 07 4月, 2019 2 次提交
  18. 30 3月, 2019 1 次提交
  19. 29 3月, 2019 1 次提交
    • B
      qmi_wwan: add Olicard 600 · 6289d0fa
      Bjørn Mork 提交于
      This is a Qualcomm based device with a QMI function on interface 4.
      It is mode switched from 2020:2030 using a standard eject message.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2031 Rev= 2.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6289d0fa
  20. 27 3月, 2019 1 次提交
  21. 04 3月, 2019 1 次提交
  22. 02 3月, 2019 1 次提交
    • Y
      drivers: net: Remove unnecessary semicolon · f819cd92
      YueHaibing 提交于
      drivers/net/dsa/mt7530.c:649:3-4: Unneeded semicolon
      drivers/net/ethernet/cisco/enic/enic_clsf.c:35:2-3: Unneeded semicolon
      drivers/net/ethernet/faraday/ftgmac100.c:1640:2-3: Unneeded semicolon
      drivers/net/ethernet/mediatek/mtk_eth_soc.c:229:2-3: Unneeded semicolon
      drivers/net/usb/sr9700.c:437:2-3: Unneeded semicolon
      
      Remove unneeded semicolon.
      
      Generated by: scripts/coccinelle/misc/semicolon.cocci
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: Sean Wang <sean.wang@mediatek.com> for mt7530 and mtk_eth_soc
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f819cd92
  23. 23 2月, 2019 1 次提交
  24. 19 2月, 2019 1 次提交
  25. 18 2月, 2019 1 次提交
  26. 09 2月, 2019 1 次提交
    • G
      net: usb: cdc-phonet: use struct_size() in alloc_netdev() · fd6d1226
      Gustavo A. R. Silva 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          void *entry[];
      };
      
      instance = alloc(sizeof(struct foo) + count * sizeof(void *));
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = alloc(struct_size(instance, entry, count));
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd6d1226