1. 31 Jul, 2020 5 commits
  2. 30 Jul, 2020 7 commits
    • Landen Chao's avatar
      net: ethernet: mtk_eth_soc: fix MTU warnings · 555a8933
      Landen Chao authored
      in recent kernel versions there are warnings about incorrect MTU size
      like these:
      
      eth0: mtu greater than device maximum
      mtk_soc_eth 1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead
      
      Fixes: bfcb8132 ("net: dsa: configure the MTU for switch ports")
      Fixes: 72579e14 ("net: dsa: don't fail to probe if we couldn't set the MTU")
      Fixes: 7a4c53be ("net: report invalid mtu value via netlink extack")
      Signed-off-by: default avatarLanden Chao <landen.chao@mediatek.com>
      Signed-off-by: default avatarFrank Wunderlich <frank-w@public-files.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      555a8933
    • Lu Wei's avatar
      net: nixge: fix potential memory leak in nixge_probe() · 366228ed
      Lu Wei authored
      If some processes in nixge_probe() fail, free_netdev(dev)
      needs to be called to aviod a memory leak.
      
      Fixes: 87ab2079 ("net: nixge: Separate ctrl and dma resources")
      Fixes: abcd3d6f ("net: nixge: Fix error path for obtaining mac address")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarLu Wei <luwei32@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      366228ed
    • Jakub Kicinski's avatar
      devlink: ignore -EOPNOTSUPP errors on dumpit · 82274d07
      Jakub Kicinski authored
      Number of .dumpit functions try to ignore -EOPNOTSUPP errors.
      Recent change missed that, and started reporting all errors
      but -EMSGSIZE back from dumps. This leads to situation like
      this:
      
      $ devlink dev info
      devlink answers: Operation not supported
      
      Dump should not report an error just because the last device
      to be queried could not provide an answer.
      
      To fix this and avoid similar confusion make sure we clear
      err properly, and not leave it set to an error if we don't
      terminate the iteration.
      
      Fixes: c62c2cfb ("net: devlink: don't ignore errors during dumpit")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82274d07
    • David Howells's avatar
      rxrpc: Fix race between recvmsg and sendmsg on immediate call failure · 65550098
      David Howells authored
      There's a race between rxrpc_sendmsg setting up a call, but then failing to
      send anything on it due to an error, and recvmsg() seeing the call
      completion occur and trying to return the state to the user.
      
      An assertion fails in rxrpc_recvmsg() because the call has already been
      released from the socket and is about to be released again as recvmsg deals
      with it.  (The recvmsg_q queue on the socket holds a ref, so there's no
      problem with use-after-free.)
      
      We also have to be careful not to end up reporting an error twice, in such
      a way that both returns indicate to userspace that the user ID supplied
      with the call is no longer in use - which could cause the client to
      malfunction if it recycles the user ID fast enough.
      
      Fix this by the following means:
      
       (1) When sendmsg() creates a call after the point that the call has been
           successfully added to the socket, don't return any errors through
           sendmsg(), but rather complete the call and let recvmsg() retrieve
           them.  Make sendmsg() return 0 at this point.  Further calls to
           sendmsg() for that call will fail with ESHUTDOWN.
      
           Note that at this point, we haven't send any packets yet, so the
           server doesn't yet know about the call.
      
       (2) If sendmsg() returns an error when it was expected to create a new
           call, it means that the user ID wasn't used.
      
       (3) Mark the call disconnected before marking it completed to prevent an
           oops in rxrpc_release_call().
      
       (4) recvmsg() will then retrieve the error and set MSG_EOR to indicate
           that the user ID is no longer known by the kernel.
      
      An oops like the following is produced:
      
      	kernel BUG at net/rxrpc/recvmsg.c:605!
      	...
      	RIP: 0010:rxrpc_recvmsg+0x256/0x5ae
      	...
      	Call Trace:
      	 ? __init_waitqueue_head+0x2f/0x2f
      	 ____sys_recvmsg+0x8a/0x148
      	 ? import_iovec+0x69/0x9c
      	 ? copy_msghdr_from_user+0x5c/0x86
      	 ___sys_recvmsg+0x72/0xaa
      	 ? __fget_files+0x22/0x57
      	 ? __fget_light+0x46/0x51
      	 ? fdget+0x9/0x1b
      	 do_recvmmsg+0x15e/0x232
      	 ? _raw_spin_unlock+0xa/0xb
      	 ? vtime_delta+0xf/0x25
      	 __x64_sys_recvmmsg+0x2c/0x2f
      	 do_syscall_64+0x4c/0x78
      	 entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 357f5ef6 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()")
      Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65550098
    • Joyce Ooi's avatar
      MAINTAINERS: Replace Thor Thayer as Altera Triple Speed Ethernet maintainer · 591eee6d
      Joyce Ooi authored
      This patch is to replace Thor Thayer as Altera Triple Speed Ethernet
      maintainer as he is moving to a different role.
      Signed-off-by: default avatarJoyce Ooi <joyce.ooi@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      591eee6d
    • Hangbin Liu's avatar
      selftests/bpf: fix netdevsim trap_flow_action_cookie read · 4bbca662
      Hangbin Liu authored
      When read netdevsim trap_flow_action_cookie, we need to init it first,
      or we will get "Invalid argument" error.
      
      Fixes: d3cbb907 ("netdevsim: add ACL trap reporting cookie as a metadata")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bbca662
    • Cong Wang's avatar
      ipv6: fix memory leaks on IPV6_ADDRFORM path · 8c0de6e9
      Cong Wang authored
      IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
      to IPv4, particularly struct ipv6_ac_socklist. Similar to
      struct ipv6_mc_socklist, we should just close it on this path.
      
      This bug can be easily reproduced with the following C program:
      
        #include <stdio.h>
        #include <string.h>
        #include <sys/types.h>
        #include <sys/socket.h>
        #include <arpa/inet.h>
      
        int main()
        {
          int s, value;
          struct sockaddr_in6 addr;
          struct ipv6_mreq m6;
      
          s = socket(AF_INET6, SOCK_DGRAM, 0);
          addr.sin6_family = AF_INET6;
          addr.sin6_port = htons(5000);
          inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
          connect(s, (struct sockaddr *)&addr, sizeof(addr));
      
          inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
          m6.ipv6mr_interface = 5;
          setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
      
          value = AF_INET;
          setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
      
          close(s);
          return 0;
        }
      
      Reported-by: ch3332xr@gmail.com
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c0de6e9
  3. 29 Jul, 2020 22 commits
    • Thomas Falcon's avatar
      ibmvnic: Fix IRQ mapping disposal in error path · 27a2145d
      Thomas Falcon authored
      RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
      error paths. Fix this and dispose of TX IRQ mappings correctly in
      case of an error.
      
      Fixes: ea22d51a ("ibmvnic: simplify and improve driver probe function")
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27a2145d
    • David S. Miller's avatar
      Merge branch 'mlxsw-fixes' · 5d104a5f
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw fixes
      
      This patch set contains various fixes for mlxsw.
      
      Patches #1-#2 fix two trap related issues introduced in previous cycle.
      
      Patches #3-#5 fix rare use-after-frees discovered by syzkaller. After
      over a week of fuzzing with the fixes, the bugs did not reproduce.
      
      Patch #6 from Amit fixes an issue in the ethtool selftest that was
      recently discovered after running the test on a new platform that
      supports only 1Gbps and 10Gbps speeds.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d104a5f
    • Amit Cohen's avatar
      selftests: ethtool: Fix test when only two speeds are supported · 10fef9ca
      Amit Cohen authored
      The test case check_highest_speed_is_chosen() configures $h1 to
      advertise a subset of its supported speeds and checks that $h2 chooses
      the highest speed from the subset.
      
      To find the common advertised speeds between $h1 and $h2,
      common_speeds_get() is called.
      
      Currently, the first speed returned from common_speeds_get() is removed
      claiming "h1 does not advertise this speed". The claim is wrong because
      the function is called after $h1 already advertised a subset of speeds.
      
      In case $h1 supports only two speeds, it will advertise a single speed
      which will be later removed because of previously mentioned bug. This
      results in the test needlessly failing. When more than two speeds are
      supported this is not an issue because the first advertised speed
      is the lowest one.
      
      Fix this by not removing any speed from the list of commonly advertised
      speeds.
      
      Fixes: 64916b57 ("selftests: forwarding: Add speed and auto-negotiation test")
      Reported-by: default avatarDanielle Ratson <danieller@mellanox.com>
      Signed-off-by: default avatarAmit Cohen <amitc@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10fef9ca
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Fix use-after-free in router init / de-init · 5515c344
      Ido Schimmel authored
      Several notifiers are registered as part of router initialization.
      Since some of these notifiers are registered before the end of the
      initialization, it is possible for them to access uninitialized or freed
      memory when processing notifications [1].
      
      Additionally, some of these notifiers queue work items on a workqueue.
      If these work items are executed after the router was de-initialized,
      they will access freed memory.
      
      Fix both problems by moving the registration of the notifiers to the end
      of the router initialization and flush the work queue after they are
      unregistered.
      
      [1]
      BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:938 [inline]
      BUG: KASAN: use-after-free in __mutex_lock+0xeea/0x1340 kernel/locking/mutex.c:1103
      Read of size 8 at addr ffff888038c3a6e0 by task kworker/u4:1/61
      
      CPU: 1 PID: 61 Comm: kworker/u4:1 Not tainted 5.8.0-rc2+ #36
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      Workqueue: mlxsw_core_ordered mlxsw_sp_inet6addr_event_work
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xf6/0x16e lib/dump_stack.c:118
       print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       __mutex_lock_common kernel/locking/mutex.c:938 [inline]
       __mutex_lock+0xeea/0x1340 kernel/locking/mutex.c:1103
       mlxsw_sp_inet6addr_event_work+0xb3/0x1b0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7123
       process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
       worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
       kthread+0x355/0x470 kernel/kthread.c:291
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
      
      Allocated by task 1298:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc mm/kasan/common.c:494 [inline]
       __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       mlxsw_sp_router_init+0xb2/0x1d20 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:8074
       mlxsw_sp_init+0xbd8/0x3ac0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2932
       __mlxsw_core_bus_device_register+0x657/0x10d0 drivers/net/ethernet/mellanox/mlxsw/core.c:1375
       mlxsw_core_bus_device_register drivers/net/ethernet/mellanox/mlxsw/core.c:1436 [inline]
       mlxsw_devlink_core_bus_device_reload_up+0xcd/0x150 drivers/net/ethernet/mellanox/mlxsw/core.c:1133
       devlink_reload net/core/devlink.c:2959 [inline]
       devlink_reload+0x281/0x3b0 net/core/devlink.c:2944
       devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
       genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
       genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
       netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
       netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
       netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
       netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0x150/0x190 net/socket.c:672
       ____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
       ___sys_sendmsg+0xff/0x170 net/socket.c:2417
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 1348:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       kasan_set_free_info mm/kasan/common.c:316 [inline]
       __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
       slab_free_hook mm/slub.c:1474 [inline]
       slab_free_freelist_hook mm/slub.c:1507 [inline]
       slab_free mm/slub.c:3072 [inline]
       kfree+0xe6/0x320 mm/slub.c:4063
       mlxsw_sp_fini+0x340/0x4e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3132
       mlxsw_core_bus_device_unregister+0x16c/0x6d0 drivers/net/ethernet/mellanox/mlxsw/core.c:1474
       mlxsw_devlink_core_bus_device_reload_down+0x8e/0xc0 drivers/net/ethernet/mellanox/mlxsw/core.c:1123
       devlink_reload+0xc6/0x3b0 net/core/devlink.c:2952
       devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
       genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
       genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
       netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
       netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
       netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
       netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0x150/0x190 net/socket.c:672
       ____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
       ___sys_sendmsg+0xff/0x170 net/socket.c:2417
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff888038c3a000
       which belongs to the cache kmalloc-2k of size 2048
      The buggy address is located 1760 bytes inside of
       2048-byte region [ffff888038c3a000, ffff888038c3a800)
      The buggy address belongs to the page:
      page:ffffea0000e30e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea0000e30e00 order:3 compound_mapcount:0 compound_pincount:0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 dead000000000100 dead000000000122 ffff88806c40c000
      raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888038c3a580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888038c3a600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff888038c3a680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff888038c3a700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888038c3a780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 965fa8e6 ("mlxsw: spectrum_router: Make RIF deletion more robust")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5515c344
    • Ido Schimmel's avatar
      mlxsw: core: Free EMAD transactions using kfree_rcu() · 3c8ce24b
      Ido Schimmel authored
      The lifetime of EMAD transactions (i.e., 'struct mlxsw_reg_trans') is
      managed using RCU. They are freed using kfree_rcu() once the transaction
      ends.
      
      However, in case the transaction failed it is freed immediately after being
      removed from the active transactions list. This is problematic because it is
      still possible for a different CPU to dereference the transaction from an RCU
      read-side critical section while traversing the active transaction list in
      mlxsw_emad_rx_listener_func(). In which case, a use-after-free is triggered
      [1].
      
      Fix this by freeing the transaction after a grace period by calling
      kfree_rcu().
      
      [1]
      BUG: KASAN: use-after-free in mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
      Read of size 8 at addr ffff88800b7964e8 by task syz-executor.2/2881
      
      CPU: 0 PID: 2881 Comm: syz-executor.2 Not tainted 5.8.0-rc4+ #44
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xf6/0x16e lib/dump_stack.c:118
       print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
       mlxsw_core_skb_receive+0x571/0x700 drivers/net/ethernet/mellanox/mlxsw/core.c:2061
       mlxsw_pci_cqe_rdq_handle drivers/net/ethernet/mellanox/mlxsw/pci.c:595 [inline]
       mlxsw_pci_cq_tasklet+0x12a6/0x2520 drivers/net/ethernet/mellanox/mlxsw/pci.c:651
       tasklet_action_common.isra.0+0x13f/0x3e0 kernel/softirq.c:550
       __do_softirq+0x223/0x964 kernel/softirq.c:292
       asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711
       </IRQ>
       __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
       run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
       do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
       invoke_softirq kernel/softirq.c:387 [inline]
       __irq_exit_rcu kernel/softirq.c:417 [inline]
       irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
       sysvec_apic_timer_interrupt+0x4e/0xd0 arch/x86/kernel/apic/apic.c:1091
       asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
      RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
      RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
      RIP: 0010:_raw_spin_unlock_irqrestore+0x3b/0x40 kernel/locking/spinlock.c:191
      Code: e8 2a c3 f4 fc 48 89 ef e8 12 96 f5 fc f6 c7 02 75 11 53 9d e8 d6 db 11 fd 65 ff 0d 1f 21 b3 56 5b 5d c3 e8 a7 d7 11 fd 53 9d <eb> ed 0f 1f 00 55 48 89 fd 65 ff 05 05 21 b3 56 ff 74 24 08 48 8d
      RSP: 0018:ffff8880446ffd80 EFLAGS: 00000286
      RAX: 0000000000000006 RBX: 0000000000000286 RCX: 0000000000000006
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa94ecea9
      RBP: ffff888012934408 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: fffffbfff57be301 R12: 1ffff110088dffc1
      R13: ffff888037b817c0 R14: ffff88802442415a R15: ffff888024424000
       __do_sys_perf_event_open+0x1b5d/0x2bd0 kernel/events/core.c:11874
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:384
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x473dbd
      Code: Bad RIP value.
      RSP: 002b:00007f21e5e9cc28 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
      RAX: ffffffffffffffda RBX: 000000000057bf00 RCX: 0000000000473dbd
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
      RBP: 000000000057bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000003 R11: 0000000000000246 R12: 000000000057bf0c
      R13: 00007ffd0493503f R14: 00000000004d0f46 R15: 00007f21e5e9cd80
      
      Allocated by task 871:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc mm/kasan/common.c:494 [inline]
       __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       mlxsw_core_reg_access_emad+0x70/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1812
       mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
       mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
       update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
       process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
       worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
       kthread+0x355/0x470 kernel/kthread.c:291
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
      
      Freed by task 871:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       kasan_set_free_info mm/kasan/common.c:316 [inline]
       __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
       slab_free_hook mm/slub.c:1474 [inline]
       slab_free_freelist_hook mm/slub.c:1507 [inline]
       slab_free mm/slub.c:3072 [inline]
       kfree+0xe6/0x320 mm/slub.c:4052
       mlxsw_core_reg_access_emad+0xd45/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1819
       mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
       mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
       update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
       process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
       worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
       kthread+0x355/0x470 kernel/kthread.c:291
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
      
      The buggy address belongs to the object at ffff88800b796400
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 232 bytes inside of
       512-byte region [ffff88800b796400, ffff88800b796600)
      The buggy address belongs to the page:
      page:ffffea00002de500 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00002de500 order:2 compound_mapcount:0 compound_pincount:0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 dead000000000100 dead000000000122 ffff88806c402500
      raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88800b796380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88800b796400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff88800b796480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                ^
       ffff88800b796500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88800b796580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: caf7297e ("mlxsw: core: Introduce support for asynchronous EMAD register access")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c8ce24b
    • Ido Schimmel's avatar
      mlxsw: core: Increase scope of RCU read-side critical section · 7d8e8f34
      Ido Schimmel authored
      The lifetime of the Rx listener item ('rxl_item') is managed using RCU,
      but is dereferenced outside of RCU read-side critical section, which can
      lead to a use-after-free.
      
      Fix this by increasing the scope of the RCU read-side critical section.
      
      Fixes: 93c1edb2 ("mlxsw: Introduce Mellanox switch driver core")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d8e8f34
    • Ido Schimmel's avatar
      mlxsw: spectrum: Use different trap group for externally routed packets · ec4f5b36
      Ido Schimmel authored
      Cited commit mistakenly removed the trap group for externally routed
      packets (e.g., via the management interface) and grouped locally routed
      and externally routed packet traps under the same group, thereby
      subjecting them to the same policer.
      
      This can result in problems, for example, when FRR is restarted and
      suddenly all transient traffic is trapped to the CPU because of a
      default route through the management interface. Locally routed packets
      required to re-establish a BGP connection will never reach the CPU and
      the routing tables will not be re-populated.
      
      Fix this by using a different trap group for externally routed packets.
      
      Fixes: 8110668e ("mlxsw: spectrum_trap: Register layer 3 control traps")
      Reported-by: default avatarAlex Veber <alexve@mellanox.com>
      Tested-by: default avatarAlex Veber <alexve@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec4f5b36
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Allow programming link-local host routes · 89ab5331
      Ido Schimmel authored
      Cited commit added the ability to program link-local prefix routes to
      the ASIC so that relevant packets are routed and trapped correctly.
      
      However, host routes were not included in the change and thus not
      programmed to the ASIC. This can result in packets being trapped via an
      external route trap instead of a local route trap as in IPv4.
      
      Fix this by programming all the link-local routes to the ASIC.
      
      Fixes: 10d3757f ("mlxsw: spectrum_router: Allow programming link-local prefix routes")
      Reported-by: default avatarAlex Veber <alexve@mellanox.com>
      Tested-by: default avatarAlex Veber <alexve@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89ab5331
    • Ido Schimmel's avatar
      ipv4: Silence suspicious RCU usage warning · 83f35228
      Ido Schimmel authored
      fib_trie_unmerge() is called with RTNL held, but not from an RCU
      read-side critical section. This leads to the following warning [1] when
      the FIB alias list in a leaf is traversed with
      hlist_for_each_entry_rcu().
      
      Since the function is always called with RTNL held and since
      modification of the list is protected by RTNL, simply use
      hlist_for_each_entry() and silence the warning.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
      -----------------------------
      net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by ip/164:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
      
      stack backtrace:
      CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       fib_trie_unmerge+0x608/0xdb0
       fib_unmerge+0x44/0x360
       fib4_rule_configure+0xc8/0xad0
       fib_nl_newrule+0x37a/0x1dd0
       rtnetlink_rcv_msg+0x4f7/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       ____sys_sendmsg+0x879/0xa00
       ___sys_sendmsg+0x122/0x190
       __sys_sendmsg+0x103/0x1d0
       __x64_sys_sendmsg+0x7d/0xb0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fc80a234e97
      Code: Bad RIP value.
      RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
      RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
      RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
      R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
      R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83f35228
    • Ido Schimmel's avatar
      vxlan: Ensure FDB dump is performed under RCU · b5141915
      Ido Schimmel authored
      The commit cited below removed the RCU read-side critical section from
      rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
      without RCU protection.
      
      This results in the following warning [1] in the VXLAN driver, which
      relied on the callback being invoked from an RCU read-side critical
      section.
      
      Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
      in the bridge driver.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
      -----------------------------
      drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by bridge/166:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
      
      stack backtrace:
      CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       vxlan_fdb_dump+0x51e/0x6d0
       rtnl_fdb_dump+0x4dc/0xad0
       netlink_dump+0x540/0x1090
       __netlink_dump_start+0x695/0x950
       rtnetlink_rcv_msg+0x802/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       __sys_sendto+0x279/0x3b0
       __x64_sys_sendto+0xe6/0x1a0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fe14fa2ade0
      Code: Bad RIP value.
      RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
      RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
      RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5141915
    • Martin Varghese's avatar
      Documentation: bareudp: Corrected description of bareudp module. · 1ed06dbc
      Martin Varghese authored
      Removed redundant words.
      
      Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
      Signed-off-by: default avatarMartin Varghese <martin.varghese@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ed06dbc
    • Guillaume Nault's avatar
      bareudp: forbid mixing IP and MPLS in multiproto mode · 302d201b
      Guillaume Nault authored
      In multiproto mode, bareudp_xmit() accepts sending multicast MPLS and
      IPv6 packets regardless of the bareudp ethertype. In practice, this
      let an IP tunnel send multicast MPLS packets, or an MPLS tunnel send
      IPv6 packets.
      
      We need to restrict the test further, so that the multiproto mode only
      enables
        * IPv6 for IPv4 tunnels,
        * or multicast MPLS for unicast MPLS tunnels.
      
      To improve clarity, the protocol validation is moved to its own
      function, where each logical test has its own condition.
      
      v2: s/ntohs/htons/
      
      Fixes: 4b5f6723 ("net: Special handling for IP & MPLS.")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      302d201b
    • Xiyu Yang's avatar
      ipv6: Fix nexthop refcnt leak when creating ipv6 route info · 706ec919
      Xiyu Yang authored
      ip6_route_info_create() invokes nexthop_get(), which increases the
      refcount of the "nh".
      
      When ip6_route_info_create() returns, local variable "nh" becomes
      invalid, so the refcount should be decreased to keep refcount balanced.
      
      The reference counting issue happens in one exception handling path of
      ip6_route_info_create(). When nexthops can not be used with source
      routing, the function forgets to decrease the refcnt increased by
      nexthop_get(), causing a refcnt leak.
      
      Fix this issue by pulling up the error source routing handling when
      nexthops can not be used with source routing.
      
      Fixes: f88d8ea6 ("ipv6: Plumb support for nexthop object in a fib6_info")
      Signed-off-by: default avatarXiyu Yang <xiyuyang19@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      706ec919
    • David S. Miller's avatar
      Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver' · fa662d78
      David S. Miller authored
      Subbaraya Sundeep says:
      
      ====================
      Fix bugs in Octeontx2 netdev driver
      
      There are problems in the existing Octeontx2
      netdev drivers like missing cancel_work for the
      reset task, missing lock in reset task and
      missing unergister_netdev in driver remove.
      This patch set fixes the above problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa662d78
    • Subbaraya Sundeep's avatar
      octeontx2-pf: Unregister netdev at driver remove · ed543f5c
      Subbaraya Sundeep authored
      Added unregister_netdev in the driver remove
      function. Generally unregister_netdev is called
      after disabling all the device interrupts but here
      it is called before disabling device mailbox
      interrupts. The reason behind this is VF needs
      mailbox interrupt to communicate with its PF to
      clean up its resources during otx2_stop.
      otx2_stop disables packet I/O and queue interrupts
      first and by using mailbox interrupt communicates
      to PF to free VF resources. Hence this patch
      calls unregister_device just before
      disabling mailbox interrupts.
      
      Fixes: 3184fb5b ("octeontx2-vf: Virtual function driver support")
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed543f5c
    • Subbaraya Sundeep's avatar
      octeontx2-pf: cancel reset_task work · c0376f47
      Subbaraya Sundeep authored
      During driver exit cancel the queued
      reset_task work in VF driver.
      
      Fixes: 3184fb5b ("octeontx2-vf: Virtual function driver support")
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0376f47
    • Subbaraya Sundeep's avatar
      octeontx2-pf: Fix reset_task bugs · 948a6633
      Subbaraya Sundeep authored
      Two bugs exist in the code related to reset_task
      in PF driver one is the missing protection
      against network stack ndo_open and ndo_close.
      Other one is the missing cancel_work.
      This patch fixes those problems.
      
      Fixes: 4ff7d148 ("octeontx2-pf: Error handling support")
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      948a6633
    • Jakub Kicinski's avatar
      mlx4: disable device on shutdown · 3cab8c65
      Jakub Kicinski authored
      It appears that not disabling a PCI device on .shutdown may lead to
      a Hardware Error with particular (perhaps buggy) BIOS versions:
      
          mlx4_en: eth0: Close port called
          mlx4_en 0000:04:00.0: removed PHC
          reboot: Restarting system
          {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
          {1}[Hardware Error]: event severity: fatal
          {1}[Hardware Error]:  Error 0, type: fatal
          {1}[Hardware Error]:   section_type: PCIe error
          {1}[Hardware Error]:   port_type: 4, root port
          {1}[Hardware Error]:   version: 1.16
          {1}[Hardware Error]:   command: 0x4010, status: 0x0143
          {1}[Hardware Error]:   device_id: 0000:00:02.2
          {1}[Hardware Error]:   slot: 0
          {1}[Hardware Error]:   secondary_bus: 0x04
          {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2f06
          {1}[Hardware Error]:   class_code: 000604
          {1}[Hardware Error]:   bridge: secondary_status: 0x2000, control: 0x0003
          {1}[Hardware Error]:   aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00000000
          {1}[Hardware Error]:   aer_uncor_severity: 0x00062030
          {1}[Hardware Error]:   TLP Header: 40000018 040000ff 791f4080 00000000
      [hw error repeats]
          Kernel panic - not syncing: Fatal hardware error!
          CPU: 0 PID: 2189 Comm: reboot Kdump: loaded Not tainted 5.6.x-blabla #1
          Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 05/05/2017
      
      Fix the mlx4 driver.
      
      This is a very similar problem to what had been fixed in:
      commit 0d98ba8d ("scsi: hpsa: disable device during shutdown")
      to address https://bugzilla.kernel.org/show_bug.cgi?id=199779.
      
      Fixes: 2ba5fbd6 ("net/mlx4_core: Handle AER flow properly")
      Reported-by: default avatarJake Lawrence <lawja@fb.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3cab8c65
    • David S. Miller's avatar
      Merge branch 'rhashtable-Fix-unprotected-RCU-dereference-in-__rht_ptr' · a7ef23e5
      David S. Miller authored
      Herbert Xu says:
      
      ====================
      rhashtable: Fix unprotected RCU dereference in __rht_ptr
      
      This patch series fixes an unprotected dereference in __rht_ptr.
      The first patch is a minimal fix that does not use the correct
      RCU markings but is suitable for backport, and the second patch
      cleans up the RCU markings.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7ef23e5
    • Herbert Xu's avatar
      rhashtable: Restore RCU marking on rhash_lock_head · ce9b362b
      Herbert Xu authored
      This patch restores the RCU marking on bucket_table->buckets as
      it really does need RCU protection.  Its removal had led to a fatal
      bug.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce9b362b
    • Herbert Xu's avatar
      rhashtable: Fix unprotected RCU dereference in __rht_ptr · 1748f6a2
      Herbert Xu authored
      The rcu_dereference call in rht_ptr_rcu is completely bogus because
      we've already dereferenced the value in __rht_ptr and operated on it.
      This causes potential double readings which could be fatal.  The RCU
      dereference must occur prior to the comparison in __rht_ptr.
      
      This patch changes the order of RCU dereference so that it is done
      first and the result is then fed to __rht_ptr.  The RCU marking
      changes have been minimised using casts which will be removed in
      a follow-up patch.
      
      Fixes: ba6306e3 ("rhashtable: Remove RCU marking from...")
      Reported-by: default avatar"Gong, Sishuai" <sishuai@purdue.edu>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1748f6a2
    • René van Dorst's avatar
      net: ethernet: mtk_eth_soc: Always call mtk_gmac0_rgmii_adjust() for mt7623 · 19016d93
      René van Dorst authored
      Modify mtk_gmac0_rgmii_adjust() so it can always be called.
      mtk_gmac0_rgmii_adjust() sets-up the TRGMII clocks.
      Signed-off-by: default avatarRené van Dorst <opensource@vdorst.com>
      Signed-off-By: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Tested-by: default avatarFrank Wunderlich <frank-w@public-files.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19016d93
  4. 28 Jul, 2020 6 commits