1. 22 Oct, 2020 1 commit
    • Xie He's avatar
      net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device · 01c4ceae
      Xie He authored
      The hdlc_rcv function is used as hdlc_packet_type.func to process any
      skb received in the kernel with skb->protocol == htons(ETH_P_HDLC).
      The purpose of this function is to provide second-stage processing for
      skbs not assigned a "real" L3 skb->protocol value in the first stage.
      
      This function assumes the device from which the skb is received is an
      HDLC device (a device created by this module). It assumes that
      netdev_priv(dev) returns a pointer to "struct hdlc_device".
      
      However, it is possible that some driver in the kernel (not necessarily
      in our control) submits a received skb with skb->protocol ==
      htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would
      still be received by hdlc_rcv. This will cause problems.
      
      hdlc_rcv should be able to recognize and drop invalid skbs. It should
      first make sure "dev" is actually an HDLC device, before starting its
      processing. This patch adds this check to hdlc_rcv.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      01c4ceae
  2. 21 Oct, 2020 16 commits
  3. 20 Oct, 2020 13 commits
  4. 19 Oct, 2020 1 commit
  5. 18 Oct, 2020 5 commits
    • Taehee Yoo's avatar
      net: core: use list_del_init() instead of list_del() in netdev_run_todo() · 0e8b8d6a
      Taehee Yoo authored
      dev->unlink_list is reused unless dev is deleted.
      So, list_del() should not be used.
      Due to using list_del(), dev->unlink_list can't be reused so that
      dev->nested_level update logic doesn't work.
      In order to fix this bug, list_del_init() should be used instead
      of list_del().
      
      Test commands:
          ip link add bond0 type bond
          ip link add bond1 type bond
          ip link set bond0 master bond1
          ip link set bond0 nomaster
          ip link set bond1 master bond0
          ip link set bond1 nomaster
      
      Splat looks like:
      [  255.750458][ T1030] ============================================
      [  255.751967][ T1030] WARNING: possible recursive locking detected
      [  255.753435][ T1030] 5.9.0-rc8+ #772 Not tainted
      [  255.754553][ T1030] --------------------------------------------
      [  255.756047][ T1030] ip/1030 is trying to acquire lock:
      [  255.757304][ T1030] ffff88811782a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync_multiple+0xc2/0x150
      [  255.760056][ T1030]
      [  255.760056][ T1030] but task is already holding lock:
      [  255.761862][ T1030] ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.764581][ T1030]
      [  255.764581][ T1030] other info that might help us debug this:
      [  255.766645][ T1030]  Possible unsafe locking scenario:
      [  255.766645][ T1030]
      [  255.768566][ T1030]        CPU0
      [  255.769415][ T1030]        ----
      [  255.770259][ T1030]   lock(&dev_addr_list_lock_key/1);
      [  255.771629][ T1030]   lock(&dev_addr_list_lock_key/1);
      [  255.772994][ T1030]
      [  255.772994][ T1030]  *** DEADLOCK ***
      [  255.772994][ T1030]
      [  255.775091][ T1030]  May be due to missing lock nesting notation
      [  255.775091][ T1030]
      [  255.777182][ T1030] 2 locks held by ip/1030:
      [  255.778299][ T1030]  #0: ffffffffb1f63250 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x2e4/0x8b0
      [  255.780600][ T1030]  #1: ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.783411][ T1030]
      [  255.783411][ T1030] stack backtrace:
      [  255.784874][ T1030] CPU: 7 PID: 1030 Comm: ip Not tainted 5.9.0-rc8+ #772
      [  255.786595][ T1030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  255.789030][ T1030] Call Trace:
      [  255.789850][ T1030]  dump_stack+0x99/0xd0
      [  255.790882][ T1030]  __lock_acquire.cold.71+0x166/0x3cc
      [  255.792285][ T1030]  ? register_lock_class+0x1a30/0x1a30
      [  255.793619][ T1030]  ? rcu_read_lock_sched_held+0x91/0xc0
      [  255.794963][ T1030]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [  255.796246][ T1030]  lock_acquire+0x1b8/0x850
      [  255.797332][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
      [  255.798624][ T1030]  ? bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.800039][ T1030]  ? check_flags+0x50/0x50
      [  255.801143][ T1030]  ? lock_contended+0xd80/0xd80
      [  255.802341][ T1030]  _raw_spin_lock_nested+0x2e/0x70
      [  255.803592][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
      [  255.804897][ T1030]  dev_mc_sync_multiple+0xc2/0x150
      [  255.806168][ T1030]  bond_enslave+0x3d58/0x43e0 [bonding]
      [  255.807542][ T1030]  ? __lock_acquire+0xe53/0x51b0
      [  255.808824][ T1030]  ? bond_update_slave_arr+0xdc0/0xdc0 [bonding]
      [  255.810451][ T1030]  ? check_chain_key+0x236/0x5e0
      [  255.811742][ T1030]  ? mutex_is_locked+0x13/0x50
      [  255.812910][ T1030]  ? rtnl_is_locked+0x11/0x20
      [  255.814061][ T1030]  ? netdev_master_upper_dev_get+0xf/0x120
      [  255.815553][ T1030]  do_setlink+0x94c/0x3040
      [ ... ]
      
      Reported-by: syzbot+4a0f7bc34e3997a6c7df@syzkaller.appspotmail.com
      Fixes: 1fc70edb ("net: core: add nested_level variable in net_device")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Link: https://lore.kernel.org/r/20201015162606.9377-1-ap420073@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0e8b8d6a
    • Jakub Kicinski's avatar
      ixgbe: fix probing of multi-port devices with one MDIO · bd7f14df
      Jakub Kicinski authored
      Ian reports that after upgrade from v5.8.14 to v5.9 only one
      of his 4 ixgbe netdevs appear in the system.
      
      Quoting the comment on ixgbe_x550em_a_has_mii():
       * Returns true if hw points to lowest numbered PCI B:D.F x550_em_a device in
       * the SoC.  There are up to 4 MACs sharing a single MDIO bus on the x550em_a,
       * but we only want to register one MDIO bus.
      
      This matches the symptoms, since the return value from
      ixgbe_mii_bus_init() is no longer ignored we need to handle
      the higher ports of x550em without an error.
      
      Fixes: 09ef193f ("net: ethernet: ixgbe: check the return value of ixgbe_mii_bus_init()")
      Reported-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
      Tested-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
      Acked-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Link: https://lore.kernel.org/r/20201016232006.3352947-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bd7f14df
    • Anant Thazhemadam's avatar
      net: usb: rtl8150: don't incorrectly assign random MAC addresses · 60f1626f
      Anant Thazhemadam authored
      In set_ethernet_addr(), if get_registers() succeeds, the ethernet address
      that was read must be copied over. Otherwise, a random ethernet address
      must be assigned.
      
      get_registers() returns 0 if successful, and negative error number
      otherwise. However, in set_ethernet_addr(), this return value is
      incorrectly checked.
      
      Since this return value will never be equal to sizeof(node_id), a
      random MAC address will always be generated and assigned to the
      device; even in cases when get_registers() is successful.
      
      Correctly modifying the condition that checks if get_registers() was
      successful or not fixes this problem, and copies the ethernet address
      appropriately.
      
      Fixes: b2a0f274 ("net: rtl8150: Use the new usb control message API.")
      Signed-off-by: default avatarAnant Thazhemadam <anant.thazhemadam@gmail.com>
      Link: https://lore.kernel.org/r/20201011173030.141582-1-anant.thazhemadam@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      60f1626f
    • Ido Schimmel's avatar
      selftests: forwarding: Add missing 'rp_filter' configuration · 71a0e29e
      Ido Schimmel authored
      When 'rp_filter' is configured in strict mode (1) the tests fail because
      packets received from the macvlan netdevs would not be forwarded through
      them on the reverse path.
      
      Fix this by disabling the 'rp_filter', meaning no source validation is
      performed.
      
      Fixes: 1538812e ("selftests: forwarding: Add a test for VXLAN asymmetric routing")
      Fixes: 438a4f56 ("selftests: forwarding: Add a test for VXLAN symmetric routing")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Tested-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Link: https://lore.kernel.org/r/20201015084525.135121-1-idosch@idosch.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      71a0e29e
    • Eelco Chaudron's avatar
      net: openvswitch: fix to make sure flow_lookup() is not preempted · f981fc3d
      Eelco Chaudron authored
      The flow_lookup() function uses per CPU variables, which must be called
      with BH disabled. However, this is fine in the general NAPI use case
      where the local BH is disabled. But, it's also called from the netlink
      context. The below patch makes sure that even in the netlink path, the
      BH is disabled.
      
      In addition, u64_stats_update_begin() requires a lock to ensure one writer
      which is not ensured here. Making it per-CPU and disabling NAPI (softirq)
      ensures that there is always only one writer.
      
      Fixes: eac87c41 ("net: openvswitch: reorder masks array based on usage")
      Reported-by: default avatarJuri Lelli <jlelli@redhat.com>
      Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Link: https://lore.kernel.org/r/160295903253.7789.826736662555102345.stgit@ebuildSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f981fc3d
  6. 16 Oct, 2020 4 commits
    • Ioana Ciornei's avatar
      net: pcs-xpcs: depend on MDIO_BUS instead of selecting it · f355a55f
      Ioana Ciornei authored
      The below compile time error can be seen when PHYLIB is configured as a
      module.
      
       ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_read':
       pcs-xpcs.c:(.text+0x29): undefined reference to `mdiobus_read'
       ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_soft_reset.constprop.7':
       pcs-xpcs.c:(.text+0x80): undefined reference to `mdiobus_write'
       ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_config_aneg':
       pcs-xpcs.c:(.text+0x318): undefined reference to `mdiobus_write'
       ld: pcs-xpcs.c:(.text+0x38e): undefined reference to `mdiobus_write'
       ld: pcs-xpcs.c:(.text+0x3eb): undefined reference to `mdiobus_write'
       ld: pcs-xpcs.c:(.text+0x437): undefined reference to `mdiobus_write'
       ld: drivers/net/pcs/pcs-xpcs.o:pcs-xpcs.c:(.text+0xb1e): more undefined references to `mdiobus_write' follow
      
      PHYLIB being a module leads to MDIO_BUS being a module as well while the
      XPCS is still built-in. What should happen in this configuration is that
      PCS_XPCS should be forced to build as module. However, that select only
      acts in the opposite way so we should turn it into a depends.
      
      Fix this up by explicitly depending on MDIO_BUS.
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Fixes: 2fa4e4b7 ("net: pcs: Move XPCS into new PCS subdirectory")
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f355a55f
    • Eric Dumazet's avatar
      icmp: randomize the global rate limiter · b38e7819
      Eric Dumazet authored
      Keyu Man reported that the ICMP rate limiter could be used
      by attackers to get useful signal. Details will be provided
      in an upcoming academic publication.
      
      Our solution is to add some noise, so that the attackers
      no longer can get help from the predictable token bucket limiter.
      
      Fixes: 4cdf507d ("icmp: add a global rate limitation")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarKeyu Man <kman001@ucr.edu>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b38e7819
    • Dylan Hung's avatar
      net: ftgmac100: Fix Aspeed ast2600 TX hang issue · 137d23ce
      Dylan Hung authored
      The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to
      hang when handling scatter-gather DMA.  Disable the problematic feature
      by setting MAC register 0x58 bit28 and bit27.
      
      Fixes: 39bfab88 ("net: ftgmac100: Add support for DT phy-handle property")
      Signed-off-by: default avatarDylan Hung <dylan_hung@aspeedtech.com>
      Reviewed-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      137d23ce
    • Hoang Huu Le's avatar
      tipc: fix incorrect setting window for bcast link · ec78e318
      Hoang Huu Le authored
      In commit 16ad3f40
      ("tipc: introduce variable window congestion control"), we applied
      the algorithm to select window size from minimum window to the
      configured maximum window for unicast link, and, besides we chose
      to keep the window size for broadcast link unchanged and equal (i.e
      fix window 50)
      
      However, when setting maximum window variable via command, the window
      variable was re-initialized to unexpect value (i.e 32).
      
      We fix this by updating the fix window for broadcast as we stated.
      
      Fixes: 16ad3f40 ("tipc: introduce variable window congestion control")
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarHoang Huu Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ec78e318