Skip to content

L
linux
Switch branch/tag
  1. 15 Jan, 2020 26 commits
  3. 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
  5. 11 Jan, 2020 7 commits
  7. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7