1. 15 Jan, 2020 26 commits
  2. 14 Jan, 2020 6 commits
    • Sunil Muthuswamy's avatar
      hv_sock: Remove the accept port restriction · c742c59e
      Sunil Muthuswamy authored
      Currently, hv_sock restricts the port the guest socket can accept
      connections on. hv_sock divides the socket port namespace into two parts
      for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF
      (there are no restrictions on client port namespace). The first part
      (0-0x7FFFFFFF) is reserved for sockets where connections can be accepted.
      The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports
      for the peer (host) socket, once a connection is accepted.
      This reservation of the port namespace is specific to hv_sock and not
      known by the generic vsock library (ex: af_vsock). This is problematic
      because auto-binds/ephemeral ports are handled by the generic vsock
      library and it has no knowledge of this port reservation and could
      allocate a port that is not compatible with hv_sock (and legitimately so).
      The issue hasn't surfaced so far because the auto-bind code of vsock
      (__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for
      VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and
      start assigning ports. That will take a large number of iterations to hit
      0x7FFFFFFF. But, after the above change to randomize port selection, the
      issue has started coming up more frequently.
      There has really been no good reason to have this port reservation logic
      in hv_sock from the get go. Reserving a local port for peer ports is not
      how things are handled generally. Peer ports should reflect the peer port.
      This fixes the issue by lifting the port reservation, and also returns the
      right peer port. Since the code converts the GUID to the peer port (by
      using the first 4 bytes), there is a possibility of conflicts, but that
      seems like a reasonable risk to take, given this is limited to vsock and
      that only applies to all local sockets.
      Signed-off-by: default avatarSunil Muthuswamy <sunilmut@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c742c59e
    • Eric Dumazet's avatar
      net: usb: lan78xx: limit size of local TSO packets · f8d7408a
      Eric Dumazet authored
      lan78xx_tx_bh() makes sure to not exceed MAX_SINGLE_PACKET_SIZE
      bytes in the aggregated packets it builds, but does
      nothing to prevent large GSO packets being submitted.
      
      Pierre-Francois reported various hangs when/if TSO is enabled.
      
      For localy generated packets, we can use netif_set_gso_max_size()
      to limit the size of TSO packets.
      
      Note that forwarded packets could still hit the issue,
      so a complete fix might require implementing .ndo_features_check
      for this driver, forcing a software segmentation if the size
      of the TSO packet exceeds MAX_SINGLE_PACKET_SIZE.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarRENARD Pierre-Francois <pfrenard@gmail.com>
      Tested-by: default avatarRENARD Pierre-Francois <pfrenard@gmail.com>
      Cc: Stefan Wahren <stefan.wahren@i2se.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f8d7408a
    • Vladis Dronov's avatar
      ptp: free ptp device pin descriptors properly · 75718584
      Vladis Dronov authored
      There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups()
      first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs
      them to destroy a related sysfs device.
      
      These functions can not be just swapped, as posix_clock_unregister() frees
      ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling
      ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed.
      
      This makes this patch fix an UAF bug in a patch which fixes an UAF bug.
      Reported-by: default avatarAntti Laakso <antti.laakso@intel.com>
      Fixes: a33121e5 ("ptp: fix the race between the release of ptp_clock and cdev")
      Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75718584
    • Johan Hovold's avatar
      NFC: pn533: fix bulk-message timeout · a112adaf
      Johan Hovold authored
      The driver was doing a synchronous uninterruptible bulk-transfer without
      using a timeout. This could lead to the driver hanging on probe due to a
      malfunctioning (or malicious) device until the device is physically
      disconnected. While sleeping in probe the driver prevents other devices
      connected to the same hub from being added to (or removed from) the bus.
      
      An arbitrary limit of five seconds should be more than enough.
      
      Fixes: dbafc289 ("NFC: pn533: don't send USB data off of the stack")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a112adaf
    • Kristian Evensen's avatar
      qmi_wwan: Add support for Quectel RM500Q · a9ff44f0
      Kristian Evensen authored
      RM500Q is a 5G module from Quectel, supporting both standalone and
      non-standalone modes. The normal Quectel quirks apply (DTR and dynamic
      interface numbers).
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a9ff44f0
    • Milind Parab's avatar
      net: macb: fix for fixed-link mode · fd2a8914
      Milind Parab authored
      This patch fix the issue with fixed link. With fixed-link
      device opening fails due to macb_phylink_connect not
      handling fixed-link mode, in which case no MAC-PHY connection
      is needed and phylink_connect return success (0), however
      in current driver attempt is made to search and connect to
      PHY even for fixed-link.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Signed-off-by: default avatarMilind Parab <mparab@cadence.com>
      Reviewed-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fd2a8914
  3. 11 Jan, 2020 7 commits
  4. 10 Jan, 2020 1 commit
    • David Ahern's avatar
      ipv4: Detect rollover in specific fib table dump · 9827c063
      David Ahern authored
      Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has
      been added to a table. The looping is caused by the key rolling over from
      FFFFFFFF to 0. When dumping a specific table only, we need a means to detect
      when the table dump is done. The key and count saved to cb args are both 0
      only at the start of the table dump. If key is 0 and count > 0, then we are
      in the rollover case. Detect and return to avoid looping.
      
      This only affects dumps of a specific table; for dumps of all tables
      (the case prior to the change in the Fixes tag) inet_dump_fib moved
      the entry counter to the next table and reset the cb args used by
      fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back
      to 0 did not cause looping with the dumps.
      
      Fixes: effe6792 ("net: Enable kernel side filtering of route dumps")
      Reported-by: default avatarSven-Haegar Koch <haegar@sdinet.de>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9827c063