1. 13 12月, 2019 4 次提交
    • N
      xfrm interface: fix management of phydev · 153bd256
      Nicolas Dichtel 提交于
      commit 22d6552f827ef76ade3edf6bbb3f05048a0a7d8b upstream.
      
      With the current implementation, phydev cannot be removed:
      
      $ ip link add dummy type dummy
      $ ip link add xfrm1 type xfrm dev dummy if_id 1
      $ ip l d dummy
       kernel:[77938.465445] unregister_netdevice: waiting for dummy to become free. Usage count = 1
      
      Manage it like in ip tunnels, ie just keep the ifindex. Not that the side
      effect, is that the phydev is now optional.
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Tested-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      153bd256
    • N
      xfrm interface: fix list corruption for x-netns · cbb62978
      Nicolas Dichtel 提交于
      commit c5d1030f23002430c2a336b2b629b9d6f72b3564 upstream.
      
      dev_net(dev) is the netns of the device and xi->net is the link netns,
      where the device has been linked.
      changelink() must operate in the link netns to avoid a corruption of
      the xfrm lists.
      
      Note that xi->net and dev_net(xi->physdev) are always the same.
      
      Before the patch, the xfrmi lists may be corrupted and can later trigger a
      kernel panic.
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Reported-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Tested-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbb62978
    • N
      xfrm interface: avoid corruption on changelink · f04f067a
      Nicolas Dichtel 提交于
      commit e9e7e85d75f3731079ffd77c1a66f037aef04fe7 upstream.
      
      The new parameters must not be stored in the netdev_priv() before
      validation, it may corrupt the interface. Note also that if data is NULL,
      only a memset() is done.
      
      $ ip link add xfrm1 type xfrm dev lo if_id 1
      $ ip link add xfrm2 type xfrm dev lo if_id 2
      $ ip link set xfrm1 type xfrm dev lo if_id 2
      RTNETLINK answers: File exists
      $ ip -d link list dev xfrm1
      5: xfrm1@lo: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/none 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu 68 maxmtu 1500
          xfrm if_id 0x2 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
      
      => "if_id 0x2"
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Tested-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f04f067a
    • N
      xfrm interface: fix memory leak on creation · 28655c63
      Nicolas Dichtel 提交于
      commit 56c5ee1a5823e9cf5288b84ae6364cb4112f8225 upstream.
      
      The following commands produce a backtrace and return an error but the xfrm
      interface is created (in the wrong netns):
      $ ip netns add foo
      $ ip netns add bar
      $ ip -n foo netns set bar 0
      $ ip -n foo link add xfrmi0 link-netnsid 0 type xfrm dev lo if_id 23
      RTNETLINK answers: Invalid argument
      $ ip -n bar link ls xfrmi0
      2: xfrmi0@lo: <NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/none 00:00:00:00:00:00 brd 00:00:00:00:00:00
      
      Here is the backtrace:
      [   79.879174] WARNING: CPU: 0 PID: 1178 at net/core/dev.c:8172 rollback_registered_many+0x86/0x3c1
      [   79.880260] Modules linked in: xfrm_interface nfsv3 nfs_acl auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache button parport_pc parport serio_raw evdev pcspkr loop ext4 crc16 mbcache jbd2 crc32c_generic ide_cd_mod ide_gd_mod cdrom ata_$
      eneric ata_piix libata scsi_mod 8139too piix psmouse i2c_piix4 ide_core 8139cp mii i2c_core floppy
      [   79.883698] CPU: 0 PID: 1178 Comm: ip Not tainted 5.2.0-rc6+ #106
      [   79.884462] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      [   79.885447] RIP: 0010:rollback_registered_many+0x86/0x3c1
      [   79.886120] Code: 01 e8 d7 7d c6 ff 0f 0b 48 8b 45 00 4c 8b 20 48 8d 58 90 49 83 ec 70 48 8d 7b 70 48 39 ef 74 44 8a 83 d0 04 00 00 84 c0 75 1f <0f> 0b e8 61 cd ff ff 48 b8 00 01 00 00 00 00 ad de 48 89 43 70 66
      [   79.888667] RSP: 0018:ffffc900015ab740 EFLAGS: 00010246
      [   79.889339] RAX: ffff8882353e5700 RBX: ffff8882353e56a0 RCX: ffff8882353e5710
      [   79.890174] RDX: ffffc900015ab7e0 RSI: ffffc900015ab7e0 RDI: ffff8882353e5710
      [   79.891029] RBP: ffffc900015ab7e0 R08: ffffc900015ab7e0 R09: ffffc900015ab7e0
      [   79.891866] R10: ffffc900015ab7a0 R11: ffffffff82233fec R12: ffffc900015ab770
      [   79.892728] R13: ffffffff81eb7ec0 R14: ffff88822ed6cf00 R15: 00000000ffffffea
      [   79.893557] FS:  00007ff350f31740(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      [   79.894581] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   79.895317] CR2: 00000000006c8580 CR3: 000000022c272000 CR4: 00000000000006f0
      [   79.896137] Call Trace:
      [   79.896464]  unregister_netdevice_many+0x12/0x6c
      [   79.896998]  __rtnl_newlink+0x6e2/0x73b
      [   79.897446]  ? __kmalloc_node_track_caller+0x15e/0x185
      [   79.898039]  ? pskb_expand_head+0x5f/0x1fe
      [   79.898556]  ? stack_access_ok+0xd/0x2c
      [   79.899009]  ? deref_stack_reg+0x12/0x20
      [   79.899462]  ? stack_access_ok+0xd/0x2c
      [   79.899927]  ? stack_access_ok+0xd/0x2c
      [   79.900404]  ? __module_text_address+0x9/0x4f
      [   79.900910]  ? is_bpf_text_address+0x5/0xc
      [   79.901390]  ? kernel_text_address+0x67/0x7b
      [   79.901884]  ? __kernel_text_address+0x1a/0x25
      [   79.902397]  ? unwind_get_return_address+0x12/0x23
      [   79.903122]  ? __cmpxchg_double_slab.isra.37+0x46/0x77
      [   79.903772]  rtnl_newlink+0x43/0x56
      [   79.904217]  rtnetlink_rcv_msg+0x200/0x24c
      
      In fact, each time a xfrm interface was created, a netdev was allocated
      by __rtnl_newlink()/rtnl_create_link() and then another one by
      xfrmi_newlink()/xfrmi_create(). Only the second one was registered, it's
      why the previous commands produce a backtrace: dev_change_net_namespace()
      was called on a netdev with reg_state set to NETREG_UNINITIALIZED (the
      first one).
      
      CC: Lorenzo Colitti <lorenzo@google.com>
      CC: Benedict Wong <benedictwong@google.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Shannon Nelson <shannon.nelson@oracle.com>
      CC: Antony Antony <antony@phenome.org>
      CC: Eyal Birger <eyal.birger@gmail.com>
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Reported-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28655c63
  2. 26 5月, 2019 1 次提交
  3. 24 3月, 2019 1 次提交
    • T
      xfrm: Fix inbound traffic via XFRM interfaces across network namespaces · 6ac400b7
      Tobias Brunner 提交于
      [ Upstream commit 660899ddf06ae8bb5bbbd0a19418b739375430c5 ]
      
      After moving an XFRM interface to another namespace it stays associated
      with the original namespace (net in `struct xfrm_if` and the list keyed
      with `xfrmi_net_id`), allowing processes in the new namespace to use
      SAs/policies that were created in the original namespace.  For instance,
      this allows a keying daemon in one namespace to establish IPsec SAs for
      other namespaces without processes there having access to the keys or IKE
      credentials.
      
      This worked fine for outbound traffic, however, for inbound traffic the
      lookup for the interfaces and the policies used the incorrect namespace
      (the one the XFRM interface was moved to).
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NTobias Brunner <tobias@strongswan.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6ac400b7
  4. 02 10月, 2018 1 次提交
  5. 27 7月, 2018 1 次提交
  6. 26 7月, 2018 1 次提交
  7. 20 7月, 2018 1 次提交
    • B
      xfrm: Remove xfrmi interface ID from flowi · bc56b334
      Benedict Wong 提交于
      In order to remove performance impact of having the extra u32 in every
      single flowi, this change removes the flowi_xfrm struct, prefering to
      take the if_id as a method parameter where needed.
      
      In the inbound direction, if_id is only needed during the
      __xfrm_check_policy() function, and the if_id can be determined at that
      point based on the skb. As such, xfrmi_decode_session() is only called
      with the skb in __xfrm_check_policy().
      
      In the outbound direction, the only place where if_id is needed is the
      xfrm_lookup() call in xfrmi_xmit2(). With this change, the if_id is
      directly passed into the xfrm_lookup_with_ifid() call. All existing
      callers can still call xfrm_lookup(), which uses a default if_id of 0.
      
      This change does not change any behavior of XFRMIs except for improving
      overall system performance via flowi size reduction.
      
      This change has been tested against the Android Kernel Networking Tests:
      
      https://android.googlesource.com/kernel/tests/+/master/net/testSigned-off-by: NBenedict Wong <benedictwong@google.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      bc56b334
  8. 23 6月, 2018 1 次提交