An error occurred fetching the project authors.
  1. 01 Jul, 2019 1 commit
  2. 01 Apr, 2019 1 commit
  3. 14 Aug, 2018 1 commit
  4. 08 Jun, 2018 2 commits
  5. 01 Nov, 2017 1 commit
    • Alexey Kodanev's avatar
      vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit · 3cba5ec2
      Alexey Kodanev authored
      BugLink: http://bugs.launchpad.net/bugs/1729105
      
      
      [ Upstream commit 36f6ee22 ]
      
      When running LTP IPsec tests, KASan might report:
      
      BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
      Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0
      ...
      Call Trace:
        <IRQ>
        dump_stack+0x63/0x89
        print_address_description+0x7c/0x290
        kasan_report+0x28d/0x370
        ? vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
        __asan_report_load4_noabort+0x19/0x20
        vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
        ? vti_init_net+0x190/0x190 [ip_vti]
        ? save_stack_trace+0x1b/0x20
        ? save_stack+0x46/0xd0
        dev_hard_start_xmit+0x147/0x510
        ? icmp_echo.part.24+0x1f0/0x210
        __dev_queue_xmit+0x1394/0x1c60
      ...
      Freed by task 0:
        save_stack_trace+0x1b/0x20
        save_stack+0x46/0xd0
        kasan_slab_free+0x70/0xc0
        kmem_cache_free+0x81/0x1e0
        kfree_skbmem+0xb1/0xe0
        kfree_skb+0x75/0x170
        kfree_skb_list+0x3e/0x60
        __dev_queue_xmit+0x1298/0x1c60
        dev_queue_xmit+0x10/0x20
        neigh_resolve_output+0x3a8/0x740
        ip_finish_output2+0x5c0/0xe70
        ip_finish_output+0x4ba/0x680
        ip_output+0x1c1/0x3a0
        xfrm_output_resume+0xc65/0x13d0
        xfrm_output+0x1e4/0x380
        xfrm4_output_finish+0x5c/0x70
      
      Can be fixed if we get skb->len before dst_output().
      
      Fixes: b9959fd3 ("vti: switch to new ip tunnel code")
      Fixes: 22e1b23d ("vti6: Support inter address family tunneling.")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cba5ec2
  6. 20 Oct, 2016 1 commit
    • Lance Richardson's avatar
      vti: flush x-netns xfrm cache when vti interface is removed · 47d12efc
      Lance Richardson authored
      BugLink: http://bugs.launchpad.net/bugs/1629386
      
      [ Upstream commit a5d0dc81 ]
      
      When executing the script included below, the netns delete operation
      hangs with the following message (repeated at 10 second intervals):
      
        kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      This occurs because a reference to the lo interface in the "secure" netns
      is still held by a dst entry in the xfrm bundle cache in the init netns.
      
      Address this problem by garbage collecting the tunnel netns flow cache
      when a cross-namespace vti interface receives a NETDEV_DOWN notification.
      
      A more detailed description of the problem scenario (referencing commands
      in the script below):
      
      (1) ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1
      
        The vti_test interface is created in the init namespace. vti_tunnel_init()
        attaches a struct ip_tunnel to the vti interface's netdev_priv(dev),
        setting the tunnel net to &init_net.
      
      (2) ip link set vti_test netns secure
      
        The vti_test interface is moved to the "secure" netns. Note that
        the associated struct ip_tunnel still has tunnel->net set to &init_net.
      
      (3) ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1
      
        The first packet sent using the vti device causes xfrm_lookup() to be
        called as follows:
      
            dst = xfrm_lookup(tunnel->net, skb_dst(skb), fl, NULL, 0);
      
        Note that tunnel->net is the init namespace, while skb_dst(skb) references
        the vti_test interface in the "secure" namespace. The returned dst
        references an interface in the init namespace.
      
        Also note that the first parameter to xfrm_lookup() determines which flow
        cache is used to store the computed xfrm bundle, so after xfrm_lookup()
        returns there will be a cached bundle in the init namespace flow cache
        with a dst referencing a device in the "secure" namespace.
      
      (4) ip netns del secure
      
        Kernel begins to delete the "secure" namespace.  At some point the
        vti_test interface is deleted, at which point dst_ifdown() changes
        the dst->dev in the cached xfrm bundle flow from vti_test to lo (still
        in the "secure" namespace however).
        Since nothing has happened to cause the init namespace's flow cache
        to be garbage collected, this dst remains attached to the flow cache,
        so the kernel loops waiting for the last reference to lo to go away.
      
      <Begin script>
      ip link add br1 type bridge
      ip link set dev br1 up
      ip addr add dev br1 1.1.1.1/8
      
      ip netns add secure
      ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1
      ip link set vti_test netns secure
      ip netns exec secure ip link set vti_test up
      ip netns exec secure ip link s lo up
      ip netns exec secure ip addr add dev lo 192.168.100.1/24
      ip netns exec secure ip route add 192.168.200.0/24 dev vti_test
      ip xfrm policy flush
      ip xfrm state flush
      ip xfrm policy add dir out tmpl src 1.1.1.1 dst 1.1.1.2 \
         proto esp mode tunnel mark 1
      ip xfrm policy add dir in tmpl src 1.1.1.2 dst 1.1.1.1 \
         proto esp mode tunnel mark 1
      ip xfrm state add src 1.1.1.1 dst 1.1.1.2 proto esp spi 1 \
         mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788
      ip xfrm state add src 1.1.1.2 dst 1.1.1.1 proto esp spi 1 \
         mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788
      
      ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1
      
      ip netns del secure
      <End script>
      Reported-by: default avatarHangbin Liu <haliu@redhat.com>
      Reported-by: default avatarJan Tluka <jtluka@redhat.com>
      Signed-off-by: default avatarLance Richardson <lrichard@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      47d12efc
  7. 08 Oct, 2015 1 commit
  8. 18 Sep, 2015 1 commit
  9. 28 May, 2015 2 commits
  10. 03 Apr, 2015 1 commit
  11. 02 Apr, 2015 1 commit
  12. 31 Mar, 2015 2 commits
  13. 19 Jan, 2015 1 commit
  14. 24 Nov, 2014 1 commit
    • lucien's avatar
      ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic · 20ea60ca
      lucien authored
      Now the vti_link_ops do not point the .dellink, for fb tunnel device
      (ip_vti0), the net_device will be removed as the default .dellink is
      unregister_netdevice_queue,but the tunnel still in the tunnel list,
      then if we add a new vti tunnel, in ip_tunnel_find():
      
              hlist_for_each_entry_rcu(t, head, hash_node) {
                      if (local == t->parms.iph.saddr &&
                          remote == t->parms.iph.daddr &&
                          link == t->parms.link &&
      ==>                 type == t->dev->type &&
                          ip_tunnel_key_match(&t->parms, flags, key))
                              break;
              }
      
      the panic will happen, cause dev of ip_tunnel *t is null:
      [ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
      [ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
      [ 3835.073008] Oops: 0000 [#1] SMP
      .....
      [ 3835.073008] Stack:
      [ 3835.073008]  ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
      [ 3835.073008]  ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
      [ 3835.073008]  ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
      [ 3835.073008] Call Trace:
      [ 3835.073008]  [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
      [ 3835.073008]  [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti]
      [ 3835.073008]  [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0
      [ 3835.073008]  [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70
      [ 3835.073008]  [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60
      [ 3835.073008]  [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0
      [ 3835.073008]  [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270
      [ 3835.073008]  [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90
      [ 3835.073008]  [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30
      [ 3835.073008]  [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0
      [ 3835.073008]  [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30
      ....
      
      modprobe ip_vti
      ip link del ip_vti0 type vti
      ip link add ip_vti0 type vti
      rmmod ip_vti
      
      do that one or more times, kernel will panic.
      
      fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
      which we skip the unregister of fb tunnel device. do the same on ip6_vti.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20ea60ca
  15. 07 Oct, 2014 1 commit
    • Eric Dumazet's avatar
      net: better IFF_XMIT_DST_RELEASE support · 02875878
      Eric Dumazet authored
      Testing xmit_more support with netperf and connected UDP sockets,
      I found strange dst refcount false sharing.
      
      Current handling of IFF_XMIT_DST_RELEASE is not optimal.
      
      Dropping dst in validate_xmit_skb() is certainly too late in case
      packet was queued by cpu X but dequeued by cpu Y
      
      The logical point to take care of drop/force is in __dev_queue_xmit()
      before even taking qdisc lock.
      
      As Julian Anastasov pointed out, need for skb_dst() might come from some
      packet schedulers or classifiers.
      
      This patch adds new helper to cleanly express needs of various drivers
      or qdiscs/classifiers.
      
      Drivers that need skb_dst() in their ndo_start_xmit() should call
      following helper in their setup instead of the prior :
      
      	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
      ->
      	netif_keep_dst(dev);
      
      Instead of using a single bit, we use two bits, one being
      eventually rebuilt in bonding/team drivers.
      
      The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
      rebuilt in bonding/team. Eventually, we could add something
      smarter later.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02875878
  16. 26 Jun, 2014 1 commit
    • Mathias Krause's avatar
      vti: Simplify error handling in module init and exit · 1990e4f8
      Mathias Krause authored
      The error handling in the module init and exit functions can be
      shortened to safe us some code.
      
      1/ Remove the code duplications in the init function, jump straight to
      the existing cleanup code by adding some labels. Also give the error
      message some more value by telling the reason why loading the module has
      failed. Furthermore fix the "IPSec" typo -- it should be "IPsec" instead.
      
      2/ Remove the error handling in the exit function as the only legitimate
      reason xfrm4_protocol_deregister() might fail is inet_del_protocol()
      returning -1. That, in turn, means some other protocol handler had been
      registered for this very protocol in the meantime. But that essentially
      means we haven't been handling that protocol any more, anyway. What it
      definitely means not is that we "can't deregister tunnel". Therefore
      just get rid of that bogus warning. It's plain wrong.
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      1990e4f8
  17. 11 Jun, 2014 1 commit
    • Dmitry Popov's avatar
      ip_vti: Fix 'ip tunnel add' with 'key' parameters · 7c8e6b9c
      Dmitry Popov authored
      ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
      translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
      TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
      making us unable to create vti tunnels with [io]key via ip tunnel.
      
      We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
      vti_tunnels with same local/remote addresses but different ikeys will be treated
      as different then. So, imo the best option here is to move p->i_flags & *_KEY
      check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
      field for ip_tunnel_parm in the future.
      Signed-off-by: default avatarDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c8e6b9c
  18. 12 May, 2014 1 commit
  19. 16 Apr, 2014 1 commit
  20. 12 Apr, 2014 1 commit
    • Nicolas Dichtel's avatar
      vti: don't allow to add the same tunnel twice · 8d89dcdf
      Nicolas Dichtel authored
      Before the patch, it was possible to add two times the same tunnel:
      ip l a vti1 type vti remote 10.16.0.121 local 10.16.0.249 key 41
      ip l a vti2 type vti remote 10.16.0.121 local 10.16.0.249 key 41
      
      It was possible, because ip_tunnel_newlink() calls ip_tunnel_find() with the
      argument dev->type, which was set only later (when calling ndo_init handler
      in register_netdevice()). Let's set this type in the setup handler, which is
      called before newlink handler.
      
      Introduced by commit b9959fd3 ("vti: switch to new ip tunnel code").
      
      CC: Cong Wang <amwang@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d89dcdf
  21. 25 Feb, 2014 5 commits
  22. 19 Jan, 2014 1 commit
  23. 05 Jan, 2014 1 commit
  24. 19 Nov, 2013 1 commit
  25. 11 Oct, 2013 1 commit
    • Christophe Gouault's avatar
      vti: get rid of nf mark rule in prerouting · 7263a518
      Christophe Gouault authored
      This patch fixes and improves the use of vti interfaces (while
      lightly changing the way of configuring them).
      
      Currently:
      
      - it is necessary to identify and mark inbound IPsec
        packets destined to each vti interface, via netfilter rules in
        the mangle table at prerouting hook.
      
      - the vti module cannot retrieve the right tunnel in input since
        commit b9959fd3: vti tunnels all have an i_key, but the tunnel lookup
        is done with flag TUNNEL_NO_KEY, so there no chance to retrieve them.
      
      - the i_key is used by the outbound processing as a mark to lookup
        for the right SP and SA bundle.
      
      This patch uses the o_key to store the vti mark (instead of i_key) and
      enables:
      
      - to avoid the need for previously marking the inbound skbuffs via a
        netfilter rule.
      - to properly retrieve the right tunnel in input, only based on the IPsec
        packet outer addresses.
      - to properly perform an inbound policy check (using the tunnel o_key
        as a mark).
      - to properly perform an outbound SPD and SAD lookup (using the tunnel
        o_key as a mark).
      - to keep the current mark of the skbuff. The skbuff mark is neither
        used nor changed by the vti interface. Only the vti interface o_key
        is used.
      
      SAs have a wildcard mark.
      SPs have a mark equal to the vti interface o_key.
      
      The vti interface must be created as follows (i_key = 0, o_key = mark):
      
         ip link add vti1 mode vti local 1.1.1.1 remote 2.2.2.2 okey 1
      
      The SPs attached to vti1 must be created as follows (mark = vti1 o_key):
      
         ip xfrm policy add dir out mark 1 tmpl src 1.1.1.1 dst 2.2.2.2 \
            proto esp mode tunnel
         ip xfrm policy add dir in  mark 1 tmpl src 2.2.2.2 dst 1.1.1.1 \
            proto esp mode tunnel
      
      The SAs are created with the default wildcard mark. There is no
      distinction between global vs. vti SAs. Just their addresses will
      possibly link them to a vti interface:
      
         ip xfrm state add src 1.1.1.1 dst 2.2.2.2 proto esp spi 1000 mode tunnel \
                       enc "cbc(aes)" "azertyuiopqsdfgh"
      
         ip xfrm state add src 2.2.2.2 dst 1.1.1.1 proto esp spi 2000 mode tunnel \
                       enc "cbc(aes)" "sqbdhgqsdjqjsdfh"
      
      To avoid matching "global" (not vti) SPs in vti interfaces, global SPs
      should no use the default wildcard mark, but explicitly match mark 0.
      
      To avoid a double SPD lookup in input and output (in global and vti SPDs),
      the NOPOLICY and NOXFRM options should be set on the vti interfaces:
      
         echo 1 > /proc/sys/net/ipv4/conf/vti1/disable_policy
         echo 1 > /proc/sys/net/ipv4/conf/vti1/disable_xfrm
      
      The outgoing traffic is steered to vti1 by a route via the vti interface:
      
         ip route add 192.168.0.0/16 dev vti1
      
      The incoming IPsec traffic is steered to vti1 because its outer addresses
      match the vti1 tunnel configuration.
      Signed-off-by: default avatarChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7263a518
  26. 28 Aug, 2013 1 commit
    • Fan Du's avatar
      {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback · aba82695
      Fan Du authored
      Some thoughts on IPv4 VTI implementation:
      
      The connection between VTI receiving part and xfrm tunnel mode input process
      is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
      and xfrm4_tunnel, acts like a true "tunnel" device.
      
      In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
      VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
      to update statistics.
      
      A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
      to check packet authentication or encryption rightness. PMTU update is taken
      care of in this stage by protocol error handler.
      
      Then the packet is rearranged properly depending on whether it's transport
      mode or tunnel mode packed by mode "input" handler. The VTI handler code
      takes effects in this stage in tunnel mode only. So it neither need propagate
      PMTU, as it has already been done if necessary, nor the VTI handler is
      qualified as a xfrm_tunnel.
      
      So this patch introduces xfrm_tunnel_notifier and meanwhile wipe out vti_err
      code.
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: David S. Miller <davem@davemloft.net>
      Reviewed-by: default avatarSaurabh Mohan <saurabh.mohan@vyatta.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      aba82695
  27. 15 Aug, 2013 1 commit
    • Nicolas Dichtel's avatar
      ipip: add x-netns support · 6c742e71
      Nicolas Dichtel authored
      This patch allows to switch the netns when packet is encapsulated or
      decapsulated. In other word, the encapsulated packet is received in a netns,
      where the lookup is done to find the tunnel. Once the tunnel is found, the
      packet is decapsulated and injecting into the corresponding interface which
      stands to another netns.
      
      When one of the two netns is removed, the tunnel is destroyed.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c742e71
  28. 24 Jul, 2013 1 commit
  29. 02 Jul, 2013 1 commit
  30. 13 Jun, 2013 1 commit
  31. 26 Mar, 2013 2 commits
    • Pravin B Shelar's avatar
      Tunneling: use IP Tunnel stats APIs. · f61dd388
      Pravin B Shelar authored
      Use common function get calculate rtnl_link_stats64 stats.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f61dd388
    • Pravin B Shelar's avatar
      GRE: Refactor GRE tunneling code. · c5441932
      Pravin B Shelar authored
      Following patch refactors GRE code into ip tunneling code and GRE
      specific code. Common tunneling code is moved to ip_tunnel module.
      ip_tunnel module is written as generic library which can be used
      by different tunneling implementations.
      
      ip_tunnel module contains following components:
       - packet xmit and rcv generic code. xmit flow looks like
         (gre_xmit/ipip_xmit)->ip_tunnel_xmit->ip_local_out.
       - hash table of all devices.
       - lookup for tunnel devices.
       - control plane operations like device create, destroy, ioctl, netlink
         operations code.
       - registration for tunneling modules, like gre, ipip etc.
       - define single pcpu_tstats dev->tstats.
       - struct tnl_ptk_info added to pass parsed tunnel packet parameters.
      
      ipip.h header is renamed to ip_tunnel.h
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5441932
  32. 19 Nov, 2012 1 commit
    • Eric W. Biederman's avatar
      net: Allow userns root to control ipv4 · 52e804c6
      Eric W. Biederman authored
      Allow an unpriviled user who has created a user namespace, and then
      created a network namespace to effectively use the new network
      namespace, by reducing capable(CAP_NET_ADMIN) and
      capable(CAP_NET_RAW) calls to be ns_capable(net->user_ns,
      CAP_NET_ADMIN), or capable(net->user_ns, CAP_NET_RAW) calls.
      
      Settings that merely control a single network device are allowed.
      Either the network device is a logical network device where
      restrictions make no difference or the network device is hardware NIC
      that has been explicity moved from the initial network namespace.
      
      In general policy and network stack state changes are allowed
      while resource control is left unchanged.
      
      Allow creating raw sockets.
      Allow the SIOCSARP ioctl to control the arp cache.
      Allow the SIOCSIFFLAG ioctl to allow setting network device flags.
      Allow the SIOCSIFADDR ioctl to allow setting a netdevice ipv4 address.
      Allow the SIOCSIFBRDADDR ioctl to allow setting a netdevice ipv4 broadcast address.
      Allow the SIOCSIFDSTADDR ioctl to allow setting a netdevice ipv4 destination address.
      Allow the SIOCSIFNETMASK ioctl to allow setting a netdevice ipv4 netmask.
      Allow the SIOCADDRT and SIOCDELRT ioctls to allow adding and deleting ipv4 routes.
      
      Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
      adding, changing and deleting gre tunnels.
      
      Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
      adding, changing and deleting ipip tunnels.
      
      Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
      adding, changing and deleting ipsec virtual tunnel interfaces.
      
      Allow setting the MRT_INIT, MRT_DONE, MRT_ADD_VIF, MRT_DEL_VIF, MRT_ADD_MFC,
      MRT_DEL_MFC, MRT_ASSERT, MRT_PIM, MRT_TABLE socket options on multicast routing
      sockets.
      
      Allow setting and receiving IPOPT_CIPSO, IP_OPT_SEC, IP_OPT_SID and
      arbitrary ip options.
      
      Allow setting IP_SEC_POLICY/IP_XFRM_POLICY ipv4 socket option.
      Allow setting the IP_TRANSPARENT ipv4 socket option.
      Allow setting the TCP_REPAIR socket option.
      Allow setting the TCP_CONGESTION socket option.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52e804c6