1. 30 Mar, 2021 3 commits
    • Kumar Kartikeya Dwivedi's avatar
      net: sched: bump refcount for new action in ACT replace mode · 6855e821
      Kumar Kartikeya Dwivedi authored
      Currently, action creation using ACT API in replace mode is buggy.
      When invoking for non-existent action index 42,
      
      	tc action replace action bpf obj foo.o sec <xyz> index 42
      
      kernel creates the action, fills up the netlink response, and then just
      deletes the action after notifying userspace.
      
      	tc action show action bpf
      
      doesn't list the action.
      
      This happens due to the following sequence when ovr = 1 (replace mode)
      is enabled:
      
      tcf_idr_check_alloc is used to atomically check and either obtain
      reference for existing action at index, or reserve the index slot using
      a dummy entry (ERR_PTR(-EBUSY)).
      
      This is necessary as pointers to these actions will be held after
      dropping the idrinfo lock, so bumping the reference count is necessary
      as we need to insert the actions, and notify userspace by dumping their
      attributes. Finally, we drop the reference we took using the
      tcf_action_put_many call in tcf_action_add. However, for the case where
      a new action is created due to free index, its refcount remains one.
      This when paired with the put_many call leads to the kernel setting up
      the action, notifying userspace of its creation, and then tearing it
      down. For existing actions, the refcount is still held so they remain
      unaffected.
      
      Fortunately due to rtnl_lock serialization requirement, such an action
      with refcount == 1 will not be concurrently deleted by anything else, at
      best CLS API can move its refcount up and down by binding to it after it
      has been published from tcf_idr_insert_many. Since refcount is atleast
      one until put_many call, CLS API cannot delete it. Also __tcf_action_put
      release path already ensures deterministic outcome (either new action
      will be created or existing action will be reused in case CLS API tries
      to bind to action concurrently) due to idr lock serialization.
      
      We fix this by making refcount of newly created actions as 2 in ACT API
      replace mode. A relaxed store will suffice as visibility is ensured only
      after the tcf_idr_insert_many call.
      
      Note that in case of creation or overwriting using CLS API only (i.e.
      bind = 1), overwriting existing action object is not allowed, and any
      such request is silently ignored (without error).
      
      The refcount bump that occurs in tcf_idr_check_alloc call there for
      existing action will pair with tcf_exts_destroy call made from the
      owner module for the same action. In case of action creation, there
      is no existing action, so no tcf_exts_destroy callback happens.
      
      This means no code changes for CLS API.
      
      Fixes: cae422f3 ("net: sched: use reference counting action init")
      Signed-off-by: default avatarKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6855e821
    • Milton Miller's avatar
      net/ncsi: Avoid channel_monitor hrtimer deadlock · 03cb4d05
      Milton Miller authored
      Calling ncsi_stop_channel_monitor from channel_monitor is a guaranteed
      deadlock on SMP because stop calls del_timer_sync on the timer that
      invoked channel_monitor as its timer function.
      
      Recognise the inherent race of marking the monitor disabled before
      deleting the timer by just returning if enable was cleared.  After
      a timeout (the default case -- reset to START when response received)
      just mark the monitor.enabled false.
      
      If the channel has an entry on the channel_queue list, or if the
      state is not ACTIVE or INACTIVE, then warn and mark the timer stopped
      and don't restart, as the locking is broken somehow.
      
      Fixes: 0795fb20 ("net/ncsi: Stop monitor if channel times out or is inactive")
      Signed-off-by: default avatarMilton Miller <miltonm@us.ibm.com>
      Signed-off-by: default avatarEddie James <eajames@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03cb4d05
    • Lv Yunlong's avatar
      ethernet/netronome/nfp: Fix a use after free in nfp_bpf_ctrl_msg_rx · 6e5a03bc
      Lv Yunlong authored
      In nfp_bpf_ctrl_msg_rx, if
      nfp_ccm_get_type(skb) == NFP_CCM_TYPE_BPF_BPF_EVENT is true, the skb
      will be freed. But the skb is still used by nfp_ccm_rx(&bpf->ccm, skb).
      
      My patch adds a return when the skb was freed.
      
      Fixes: bcf0cafa ("nfp: split out common control message handling code")
      Signed-off-by: default avatarLv Yunlong <lyl2019@mail.ustc.edu.cn>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e5a03bc
  2. 29 Mar, 2021 26 commits
  3. 26 Mar, 2021 10 commits
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 75887e88
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2021-03-25
      
      This series contains updates to virtchnl header file and i40e driver.
      
      Norbert removes added padding from virtchnl RSS structures as this
      causes issues when iterating over the arrays.
      
      Mateusz adds Asym_Pause as supported to allow these settings to be set
      as the hardware supports it.
      
      Eryk fixes an issue where encountering a VF reset alongside releasing
      VFs could cause a call trace.
      
      Arkadiusz moves TC setup before resource setup as previously it was
      possible to enter with a null q_vector causing a kernel oops.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75887e88
    • Eric Dumazet's avatar
      sch_red: fix off-by-one checks in red_check_params() · 3a87571f
      Eric Dumazet authored
      This fixes following syzbot report:
      
      UBSAN: shift-out-of-bounds in ./include/net/red.h:237:23
      shift exponent 32 is too large for 32-bit type 'unsigned int'
      CPU: 1 PID: 8418 Comm: syz-executor170 Not tainted 5.12.0-rc4-next-20210324-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:79 [inline]
       dump_stack+0x141/0x1d7 lib/dump_stack.c:120
       ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
       __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
       red_set_parms include/net/red.h:237 [inline]
       choke_change.cold+0x3c/0xc8 net/sched/sch_choke.c:414
       qdisc_create+0x475/0x12f0 net/sched/sch_api.c:1247
       tc_modify_qdisc+0x4c8/0x1a50 net/sched/sch_api.c:1663
       rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
       netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
       netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
       netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:674
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x43f039
      Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffdfa725168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043f039
      RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004
      RBP: 0000000000403020 R08: 0000000000400488 R09: 0000000000400488
      R10: 0000000000400488 R11: 0000000000000246 R12: 00000000004030b0
      R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488
      
      Fixes: 8afa10cb ("net_sched: red: Avoid illegal values")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a87571f
    • David S. Miller's avatar
      Merge branch 'tunnel-shinfo' · 3cec1921
      David S. Miller authored
      Antoine Tenart says:
      
      ====================
      net: do not modify the shared tunnel info when PMTU triggers an ICMP reply
      
      The series fixes an issue were a shared ip_tunnel_info is modified when
      PMTU triggers an ICMP reply in vxlan and geneve, making following
      packets in that flow to have a wrong destination address if the flow
      isn't updated. A detailled information is given in each of the two
      commits.
      
      This was tested manually with OVS and I ran the PTMU selftests with
      kmemleak enabled (all OK, none was skipped).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3cec1921
    • Antoine Tenart's avatar
      geneve: do not modify the shared tunnel info when PMTU triggers an ICMP reply · 68c1a943
      Antoine Tenart authored
      When the interface is part of a bridge or an Open vSwitch port and a
      packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
      using the external mode (collect metadata) the source and destination
      addresses are reversed, so that Open vSwitch can match the packet
      against an existing (reverse) flow.
      
      But inverting the source and destination addresses in the shared
      ip_tunnel_info will make following packets of the flow to use a wrong
      destination address (packets will be tunnelled to itself), if the flow
      isn't updated. Which happens with Open vSwitch, until the flow times
      out.
      
      Fixes this by uncloning the skb's ip_tunnel_info before inverting its
      source and destination addresses, so that the modification will only be
      made for the PTMU packet, not the following ones.
      
      Fixes: c1a800e8 ("geneve: Support for PMTU discovery on directly bridged links")
      Tested-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Reviewed-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Signed-off-by: default avatarAntoine Tenart <atenart@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68c1a943
    • Antoine Tenart's avatar
      vxlan: do not modify the shared tunnel info when PMTU triggers an ICMP reply · 30a93d2b
      Antoine Tenart authored
      When the interface is part of a bridge or an Open vSwitch port and a
      packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
      using the external mode (collect metadata) the source and destination
      addresses are reversed, so that Open vSwitch can match the packet
      against an existing (reverse) flow.
      
      But inverting the source and destination addresses in the shared
      ip_tunnel_info will make following packets of the flow to use a wrong
      destination address (packets will be tunnelled to itself), if the flow
      isn't updated. Which happens with Open vSwitch, until the flow times
      out.
      
      Fixes this by uncloning the skb's ip_tunnel_info before inverting its
      source and destination addresses, so that the modification will only be
      made for the PTMU packet, not the following ones.
      
      Fixes: fc68c995 ("vxlan: Support for PMTU discovery on directly bridged links")
      Tested-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Reviewed-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Signed-off-by: default avatarAntoine Tenart <atenart@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30a93d2b
    • David S. Miller's avatar
      Merge branch 'nfc-fixes' · aa5a5b7a
      David S. Miller authored
      Xiaoming Ni says:
      
      ====================
      nfc: fix Resource leakage and endless loop
      
      fix Resource leakage and endless loop in net/nfc/llcp_sock.c,
       reported by "kiyin(尹亮)".
      
      Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
      ====================
      math: Export mul_u64_u64_div_u64
      
      Fixes: f51d7bf1 ("ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa5a5b7a
    • Xiaoming Ni's avatar
      nfc: Avoid endless loops caused by repeated llcp_sock_connect() · 4b5db93e
      Xiaoming Ni authored
      When sock_wait_state() returns -EINPROGRESS, "sk->sk_state" is
       LLCP_CONNECTING. In this case, llcp_sock_connect() is repeatedly invoked,
       nfc_llcp_sock_link() will add sk to local->connecting_sockets twice.
       sk->sk_node->next will point to itself, that will make an endless loop
       and hang-up the system.
      To fix it, check whether sk->sk_state is LLCP_CONNECTING in
       llcp_sock_connect() to avoid repeated invoking.
      
      Fixes: b4011239 ("NFC: llcp: Fix non blocking sockets connections")
      Reported-by: default avatar"kiyin(尹亮)" <kiyin@tencent.com>
      Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
      Cc: <stable@vger.kernel.org> #v3.11
      Signed-off-by: default avatarXiaoming Ni <nixiaoming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b5db93e
    • Xiaoming Ni's avatar
      nfc: fix memory leak in llcp_sock_connect() · 7574fcdb
      Xiaoming Ni authored
      In llcp_sock_connect(), use kmemdup to allocate memory for
       "llcp_sock->service_name". The memory is not released in the sock_unlink
      label of the subsequent failure branch.
      As a result, memory leakage occurs.
      
      fix CVE-2020-25672
      
      Fixes: d646960f ("NFC: Initial LLCP support")
      Reported-by: default avatar"kiyin(尹亮)" <kiyin@tencent.com>
      Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
      Cc: <stable@vger.kernel.org> #v3.3
      Signed-off-by: default avatarXiaoming Ni <nixiaoming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7574fcdb
    • Xiaoming Ni's avatar
      nfc: fix refcount leak in llcp_sock_connect() · 8a4cd82d
      Xiaoming Ni authored
      nfc_llcp_local_get() is invoked in llcp_sock_connect(),
      but nfc_llcp_local_put() is not invoked in subsequent failure branches.
      As a result, refcount leakage occurs.
      To fix it, add calling nfc_llcp_local_put().
      
      fix CVE-2020-25671
      Fixes: c7aa1225 ("NFC: Take a reference on the LLCP local pointer when creating a socket")
      Reported-by: default avatar"kiyin(尹亮)" <kiyin@tencent.com>
      Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
      Cc: <stable@vger.kernel.org> #v3.6
      Signed-off-by: default avatarXiaoming Ni <nixiaoming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a4cd82d
    • Xiaoming Ni's avatar
      nfc: fix refcount leak in llcp_sock_bind() · c33b1cc6
      Xiaoming Ni authored
      nfc_llcp_local_get() is invoked in llcp_sock_bind(),
      but nfc_llcp_local_put() is not invoked in subsequent failure branches.
      As a result, refcount leakage occurs.
      To fix it, add calling nfc_llcp_local_put().
      
      fix CVE-2020-25670
      Fixes: c7aa1225 ("NFC: Take a reference on the LLCP local pointer when creating a socket")
      Reported-by: default avatar"kiyin(尹亮)" <kiyin@tencent.com>
      Link: https://www.openwall.com/lists/oss-security/2020/11/01/1
      Cc: <stable@vger.kernel.org> #v3.6
      Signed-off-by: default avatarXiaoming Ni <nixiaoming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c33b1cc6
  4. 25 Mar, 2021 1 commit