1. 01 6月, 2018 2 次提交
    • P
      rtnetlink: Fix null-ptr-deref in rtnl_newlink · af066ed3
      Prashant Bhole 提交于
      In rtnl_newlink(), NULL check is performed on m_ops however member of
      ops is accessed. Fixed by accessing member of m_ops instead of ops.
      
      [  345.432629] BUG: KASAN: null-ptr-deref in rtnl_newlink+0x400/0x1110
      [  345.432629] Read of size 4 at addr 0000000000000088 by task ip/986
      [  345.432629]
      [  345.432629] CPU: 1 PID: 986 Comm: ip Not tainted 4.17.0-rc6+ #9
      [  345.432629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  345.432629] Call Trace:
      [  345.432629]  dump_stack+0xc6/0x150
      [  345.432629]  ? dump_stack_print_info.cold.0+0x1b/0x1b
      [  345.432629]  ? kasan_report+0xb4/0x410
      [  345.432629]  kasan_report.cold.4+0x8f/0x91
      [  345.432629]  ? rtnl_newlink+0x400/0x1110
      [  345.432629]  rtnl_newlink+0x400/0x1110
      [...]
      
      Fixes: ccf8dbcd ("rtnetlink: Remove VLA usage")
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Tested-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af066ed3
    • K
      rtnetlink: Remove VLA usage · ccf8dbcd
      Kees Cook 提交于
      In the quest to remove all stack VLA usage from the kernel[1], this
      allocates the maximum size expected for all possible types and adds
      sanity-checks at both registration and usage to make sure nothing gets
      out of sync. This matches the proposed VLA solution for nfnetlink[2]. The
      values chosen here were based on finding assignments for .maxtype and
      .slave_maxtype and manually counting the enums:
      
      slave_maxtype (max 33):
      	IFLA_BRPORT_MAX     33
      	IFLA_BOND_SLAVE_MAX  9
      
      maxtype (max 45):
      	IFLA_BOND_MAX       28
      	IFLA_BR_MAX         45
      	__IFLA_CAIF_HSI_MAX  8
      	IFLA_CAIF_MAX        4
      	IFLA_CAN_MAX        16
      	IFLA_GENEVE_MAX     12
      	IFLA_GRE_MAX        25
      	IFLA_GTP_MAX         5
      	IFLA_HSR_MAX         7
      	IFLA_IPOIB_MAX       4
      	IFLA_IPTUN_MAX      21
      	IFLA_IPVLAN_MAX      3
      	IFLA_MACSEC_MAX     15
      	IFLA_MACVLAN_MAX     7
      	IFLA_PPP_MAX         2
      	__IFLA_RMNET_MAX     4
      	IFLA_VLAN_MAX        6
      	IFLA_VRF_MAX         2
      	IFLA_VTI_MAX         7
      	IFLA_VXLAN_MAX      28
      	VETH_INFO_MAX        2
      	VXCAN_INFO_MAX       2
      
      This additionally changes maxtype and slave_maxtype fields to unsigned,
      since they're only ever using positive values.
      
      [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
      [2] https://patchwork.kernel.org/patch/10439647/Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccf8dbcd
  2. 18 4月, 2018 1 次提交
  3. 01 4月, 2018 1 次提交
    • K
      net: Do not take net_rwsem in __rtnl_link_unregister() · 554873e5
      Kirill Tkhai 提交于
      This function calls call_netdevice_notifier(), which also
      may take net_rwsem. So, we can't use net_rwsem here.
      
      This patch makes callers of this functions take pernet_ops_rwsem,
      like register_netdevice_notifier() does. This will protect
      the modifications of net_namespace_list, and allows notifiers
      to take it (they won't have to care about context).
      
      Since __rtnl_link_unregister() is used on module load
      and unload (which are not frequent operations), this looks
      for me better, than make all call_netdevice_notifier()
      always executing in "protected net_namespace_list" context.
      
      Also, this fixes the problem we had a deal in 328fbe74
      "Close race between {un, }register_netdevice_notifier and ...",
      and guarantees __rtnl_link_unregister() does not skip
      exitting net.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      554873e5
  4. 30 3月, 2018 1 次提交
    • K
      net: Introduce net_rwsem to protect net_namespace_list · f0b07bb1
      Kirill Tkhai 提交于
      rtnl_lock() is used everywhere, and contention is very high.
      When someone wants to iterate over alive net namespaces,
      he/she has no a possibility to do that without exclusive lock.
      But the exclusive rtnl_lock() in such places is overkill,
      and it just increases the contention. Yes, there is already
      for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
      and this can't be sleepable. Also, sometimes it may be need
      really prevent net_namespace_list growth, so for_each_net_rcu()
      is not fit there.
      
      This patch introduces new rw_semaphore, which will be used
      instead of rtnl_mutex to protect net_namespace_list. It is
      sleepable and allows not-exclusive iterations over net
      namespaces list. It allows to stop using rtnl_lock()
      in several places (what is made in next patches) and makes
      less the time, we keep rtnl_mutex. Here we just add new lock,
      while the explanation of we can remove rtnl_lock() there are
      in next patches.
      
      Fine grained locks generally are better, then one big lock,
      so let's do that with net_namespace_list, while the situation
      allows that.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0b07bb1
  5. 28 3月, 2018 3 次提交
  6. 17 3月, 2018 1 次提交
    • K
      net: Add rtnl_lock_killable() · 79ffdfc6
      Kirill Tkhai 提交于
      rtnl_lock() is widely used mutex in kernel. Some of kernel code
      does memory allocations under it. In case of memory deficit this
      may invoke OOM killer, but the problem is a killed task can't
      exit if it's waiting for the mutex. This may be a reason of deadlock
      and panic.
      
      This patch adds a new primitive, which responds on SIGKILL, and
      it allows to use it in the places, where we don't want to sleep
      forever.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79ffdfc6
  7. 13 2月, 2018 2 次提交
    • K
      net: Convert rtnetlink_net_ops · 46456675
      Kirill Tkhai 提交于
      rtnetlink_net_init() and rtnetlink_net_exit()
      create and destroy netlink socket net::rtnl.
      
      The socket is used to send rtnl notification via
      rtnl_net_notifyid(). There is no a problem
      to create and destroy it in parallel with other
      pernet operations, as we link net in setup_net()
      after the socket is created, and destroy
      in cleanup_net() after net is unhashed from all
      the lists and there is no RCU references on it.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Acked-by: NAndrei Vagin <avagin@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46456675
    • K
      net: Introduce net_sem for protection of pernet_list · 1a57feb8
      Kirill Tkhai 提交于
      Currently, the mutex is mostly used to protect pernet operations
      list. It orders setup_net() and cleanup_net() with parallel
      {un,}register_pernet_operations() calls, so ->exit{,batch} methods
      of the same pernet operations are executed for a dying net, as
      were used to call ->init methods, even after the net namespace
      is unlinked from net_namespace_list in cleanup_net().
      
      But there are several problems with scalability. The first one
      is that more than one net can't be created or destroyed
      at the same moment on the node. For big machines with many cpus
      running many containers it's very sensitive.
      
      The second one is that it's need to synchronize_rcu() after net
      is removed from net_namespace_list():
      
      Destroy net_ns:
      cleanup_net()
        mutex_lock(&net_mutex)
        list_del_rcu(&net->list)
        synchronize_rcu()                                  <--- Sleep there for ages
        list_for_each_entry_reverse(ops, &pernet_list, list)
          ops_exit_list(ops, &net_exit_list)
        list_for_each_entry_reverse(ops, &pernet_list, list)
          ops_free_list(ops, &net_exit_list)
        mutex_unlock(&net_mutex)
      
      This primitive is not fast, especially on the systems with many processors
      and/or when preemptible RCU is enabled in config. So, all the time, while
      cleanup_net() is waiting for RCU grace period, creation of new net namespaces
      is not possible, the tasks, who makes it, are sleeping on the same mutex:
      
      Create net_ns:
      copy_net_ns()
        mutex_lock_killable(&net_mutex)                    <--- Sleep there for ages
      
      I observed 20-30 seconds hangs of "unshare -n" on ordinary 8-cpu laptop
      with preemptible RCU enabled after CRIU tests round is finished.
      
      The solution is to convert net_mutex to the rw_semaphore and add fine grain
      locks to really small number of pernet_operations, what really need them.
      
      Then, pernet_operations::init/::exit methods, modifying the net-related data,
      will require down_read() locking only, while down_write() will be used
      for changing pernet_list (i.e., when modules are being loaded and unloaded).
      
      This gives signify performance increase, after all patch set is applied,
      like you may see here:
      
      %for i in {1..10000}; do unshare -n bash -c exit; done
      
      *before*
      real 1m40,377s
      user 0m9,672s
      sys 0m19,928s
      
      *after*
      real 0m17,007s
      user 0m5,311s
      sys 0m11,779
      
      (5.8 times faster)
      
      This patch starts replacing net_mutex to net_sem. It adds rw_semaphore,
      describes the variables it protects, and makes to use, where appropriate.
      net_mutex is still present, and next patches will kick it out step-by-step.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Acked-by: NAndrei Vagin <avagin@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a57feb8
  8. 09 2月, 2018 1 次提交
    • C
      rtnetlink: require unique netns identifier · 4ff66cae
      Christian Brauner 提交于
      Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK
      it is possible for userspace to send us requests with three different
      properties to identify a target network namespace. This affects at least
      RTM_{NEW,SET}LINK. Each of them could potentially refer to a different
      network namespace which is confusing. For legacy reasons the kernel will
      pick the IFLA_NET_NS_PID property first and then look for the
      IFLA_NET_NS_FD property but there is no reason to extend this type of
      behavior to network namespace ids. The regression potential is quite
      minimal since the rtnetlink requests in question either won't allow
      IFLA_IF_NETNSID requests before 4.16 is out (RTM_{NEW,SET}LINK) or don't
      support IFLA_NET_NS_{PID,FD} (RTM_{DEL,GET}LINK) in the first place.
      Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
      Acked-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ff66cae
  9. 01 2月, 2018 1 次提交
  10. 31 1月, 2018 1 次提交
    • C
      rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK · 5bb8ed07
      Christian Brauner 提交于
      - Backwards Compatibility:
        If userspace wants to determine whether RTM_NEWLINK supports the
        IFLA_IF_NETNSID property they should first send an RTM_GETLINK request
        with IFLA_IF_NETNSID on lo. If either EACCESS is returned or the reply
        does not include IFLA_IF_NETNSID userspace should assume that
        IFLA_IF_NETNSID is not supported on this kernel.
        If the reply does contain an IFLA_IF_NETNSID property userspace
        can send an RTM_NEWLINK with a IFLA_IF_NETNSID property. If they receive
        EOPNOTSUPP then the kernel does not support the IFLA_IF_NETNSID property
        with RTM_NEWLINK. Userpace should then fallback to other means.
      
      - Security:
        Callers must have CAP_NET_ADMIN in the owning user namespace of the
        target network namespace.
      Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bb8ed07
  11. 30 1月, 2018 5 次提交
    • C
      net: introduce helper dev_change_tx_queue_len() · 6a643ddb
      Cong Wang 提交于
      This patch promotes the local change_tx_queue_len() to a core
      helper function, dev_change_tx_queue_len(), so that rtnetlink
      and net-sysfs could share the code. This also prepares for the
      following patch.
      
      Note, the -EFAULT in the original code doesn't make sense,
      we should propagate the errno from notifiers.
      
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a643ddb
    • N
      dev: advertise the new ifindex when the netns iface changes · 38e01b30
      Nicolas Dichtel 提交于
      The goal is to let the user follow an interface that moves to another
      netns.
      
      CC: Jiri Benc <jbenc@redhat.com>
      CC: Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Reviewed-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38e01b30
    • C
      rtnetlink: enable IFLA_IF_NETNSID for RTM_DELLINK · b61ad68a
      Christian Brauner 提交于
      - Backwards Compatibility:
        If userspace wants to determine whether RTM_DELLINK supports the
        IFLA_IF_NETNSID property they should first send an RTM_GETLINK request
        with IFLA_IF_NETNSID on lo. If either EACCESS is returned or the reply
        does not include IFLA_IF_NETNSID userspace should assume that
        IFLA_IF_NETNSID is not supported on this kernel.
        If the reply does contain an IFLA_IF_NETNSID property userspace
        can send an RTM_DELLINK with a IFLA_IF_NETNSID property. If they receive
        EOPNOTSUPP then the kernel does not support the IFLA_IF_NETNSID property
        with RTM_DELLINK. Userpace should then fallback to other means.
      
      - Security:
        Callers must have CAP_NET_ADMIN in the owning user namespace of the
        target network namespace.
      Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b61ad68a
    • C
      rtnetlink: enable IFLA_IF_NETNSID for RTM_SETLINK · c310bfcb
      Christian Brauner 提交于
      - Backwards Compatibility:
        If userspace wants to determine whether RTM_SETLINK supports the
        IFLA_IF_NETNSID property they should first send an RTM_GETLINK request
        with IFLA_IF_NETNSID on lo. If either EACCESS is returned or the reply
        does not include IFLA_IF_NETNSID userspace should assume that
        IFLA_IF_NETNSID is not supported on this kernel.
        If the reply does contain an IFLA_IF_NETNSID property userspace
        can send an RTM_SETLINK with a IFLA_IF_NETNSID property. If they receive
        EOPNOTSUPP then the kernel does not support the IFLA_IF_NETNSID property
        with RTM_SETLINK. Userpace should then fallback to other means.
      
        To retain backwards compatibility the kernel will first check whether a
        IFLA_NET_NS_PID or IFLA_NET_NS_FD property has been passed. If either
        one is found it will be used to identify the target network namespace.
        This implies that users who do not care whether their running kernel
        supports IFLA_IF_NETNSID with RTM_SETLINK can pass both
        IFLA_NET_NS_{FD,PID} and IFLA_IF_NETNSID referring to the same network
        namespace.
      
      - Security:
        Callers must have CAP_NET_ADMIN in the owning user namespace of the
        target network namespace.
      Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c310bfcb
    • C
      rtnetlink: enable IFLA_IF_NETNSID in do_setlink() · 7c4f63ba
      Christian Brauner 提交于
      RTM_{NEW,SET}LINK already allow operations on other network namespaces
      by identifying the target network namespace through IFLA_NET_NS_{FD,PID}
      properties. This is done by looking for the corresponding properties in
      do_setlink(). Extend do_setlink() to also look for the IFLA_IF_NETNSID
      property. This introduces no functional changes since all callers of
      do_setlink() currently block IFLA_IF_NETNSID by reporting an error before
      they reach do_setlink().
      
      This introduces the helpers:
      
      static struct net *rtnl_link_get_net_by_nlattr(struct net *src_net, struct
                                                     nlattr *tb[])
      
      static struct net *rtnl_link_get_net_capable(const struct sk_buff *skb,
                                                   struct net *src_net,
      					     struct nlattr *tb[], int cap)
      
      to simplify permission checks and target network namespace retrieval for
      RTM_* requests that already support IFLA_NET_NS_{FD,PID} but get extended
      to IFLA_IF_NETNSID. To perserve backwards compatibility the helpers look
      for IFLA_NET_NS_{FD,PID} properties first before checking for
      IFLA_IF_NETNSID.
      Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c4f63ba
  12. 23 1月, 2018 1 次提交
  13. 09 1月, 2018 1 次提交
  14. 05 1月, 2018 1 次提交
    • A
      rtnetlink: give a user socket to get_target_net() · f428fe4a
      Andrei Vagin 提交于
      This function is used from two places: rtnl_dump_ifinfo and
      rtnl_getlink. In rtnl_getlink(), we give a request skb into
      get_target_net(), but in rtnl_dump_ifinfo, we give a response skb
      into get_target_net().
      The problem here is that NETLINK_CB() isn't initialized for the response
      skb. In both cases we can get a user socket and give it instead of skb
      into get_target_net().
      
      This bug was found by syzkaller with this call-trace:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868
      RSP: 0018:ffff8801c880f348 EFLAGS: 00010206
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8443f900
      RDX: 000000000000007b RSI: ffffffff86510f40 RDI: 00000000000003d8
      RBP: ffff8801c880f360 R08: 0000000000000000 R09: 1ffff10039101e4f
      R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86510f40
      R13: 000000000000000c R14: 0000000000000004 R15: 0000000000000011
      FS:  0000000001a1a880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020151000 CR3: 00000001c9511005 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        netlink_ns_capable+0x26/0x30 net/netlink/af_netlink.c:886
        get_target_net+0x9d/0x120 net/core/rtnetlink.c:1765
        rtnl_dump_ifinfo+0x2e5/0xee0 net/core/rtnetlink.c:1806
        netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:2222
        __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2319
        netlink_dump_start include/linux/netlink.h:214 [inline]
        rtnetlink_rcv_msg+0x7f0/0xb10 net/core/rtnetlink.c:4485
        netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2441
        rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
        netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
        netlink_unicast+0x4be/0x6a0 net/netlink/af_netlink.c:1334
        netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
      
      Cc: Jiri Benc <jbenc@redhat.com>
      Fixes: 79e1ad14 ("rtnetlink: use netnsid to query interface")
      Signed-off-by: NAndrei Vagin <avagin@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f428fe4a
  15. 11 12月, 2017 1 次提交
  16. 09 12月, 2017 1 次提交
  17. 06 12月, 2017 1 次提交
  18. 05 12月, 2017 4 次提交
  19. 03 12月, 2017 1 次提交
  20. 08 11月, 2017 1 次提交
  21. 05 11月, 2017 2 次提交
    • J
      net: bpf: rename ndo_xdp to ndo_bpf · f4e63525
      Jakub Kicinski 提交于
      ndo_xdp is a control path callback for setting up XDP in the
      driver.  We can reuse it for other forms of communication
      between the eBPF stack and the drivers.  Rename the callback
      and associated structures and definitions.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4e63525
    • J
      rtnetlink: use netnsid to query interface · 79e1ad14
      Jiri Benc 提交于
      Currently, when an application gets netnsid from the kernel (for example as
      the result of RTM_GETLINK call on one end of the veth pair), it's not much
      useful. There's no reliable way to get to the netns fd from the netnsid, nor
      does any kernel API accept netnsid.
      
      Extend the RTM_GETLINK call to also accept netnsid. It will operate on the
      netns with the given netnsid in such case. Of course, the calling process
      needs to have enough capabilities in the target name space; for now, require
      CAP_NET_ADMIN. This can be relaxed in the future.
      
      To signal to the calling process that the kernel understood the new
      IFLA_IF_NETNSID attribute in the query, it will include it in the response.
      This is needed to detect older kernels, as they will just ignore
      IFLA_IF_NETNSID and query in the current name space.
      
      This patch implemetns IFLA_IF_NETNSID only for get and dump. For set
      operations, this can be extended later.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79e1ad14
  22. 25 10月, 2017 2 次提交
  23. 23 10月, 2017 1 次提交
  24. 17 10月, 2017 4 次提交