1. 14 2月, 2020 1 次提交
  2. 04 2月, 2020 1 次提交
  3. 15 1月, 2020 1 次提交
  4. 14 1月, 2020 2 次提交
  5. 09 12月, 2019 2 次提交
  6. 22 11月, 2019 1 次提交
  7. 12 11月, 2019 1 次提交
    • X
      xfrm: release device reference for invalid state · 4944a4b1
      Xiaodong Xu 提交于
      An ESP packet could be decrypted in async mode if the input handler for
      this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
      reference in skb is held. Later xfrm_input() will be invoked again to
      resume the processing.
      If the transform state is still valid it would continue to release the
      device reference and there won't be a problem; however if the transform
      state is not valid when async resumption happens, the packet will be
      dropped while the device reference is still being held.
      When the device is deleted for some reason and the reference to this
      device is not properly released, the kernel will keep logging like:
      
      unregister_netdevice: waiting for ppp2 to become free. Usage count = 1
      
      The issue is observed when running IPsec traffic over a PPPoE device based
      on a bridge interface. By terminating the PPPoE connection on the server
      end for multiple times, the PPPoE device on the client side will eventually
      get stuck on the above warning message.
      
      This patch will check the async mode first and continue to release device
      reference in async resumption, before it is dropped due to invalid state.
      
      v2: Do not assign address family from outer_mode in the transform if the
      state is invalid
      
      v3: Release device reference in the error path instead of jumping to resume
      
      Fixes: 4ce3dbe3 ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
      Signed-off-by: NXiaodong Xu <stid.smth@gmail.com>
      Reported-by: NBo Chen <chenborfc@163.com>
      Tested-by: NBo Chen <chenborfc@163.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4944a4b1
  8. 07 11月, 2019 1 次提交
  9. 01 11月, 2019 2 次提交
    • E
      crypto: skcipher - rename the crypto_blkcipher module and kconfig option · b95bba5d
      Eric Biggers 提交于
      Now that the blkcipher algorithm type has been removed in favor of
      skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher,
      and rename the config options accordingly:
      
      	CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER
      	CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b95bba5d
    • E
      crypto: skcipher - remove the "blkcipher" algorithm type · c65058b7
      Eric Biggers 提交于
      Now that all "blkcipher" algorithms have been converted to "skcipher",
      remove the blkcipher algorithm type.
      
      The skcipher (symmetric key cipher) algorithm type was introduced a few
      years ago to replace both blkcipher and ablkcipher (synchronous and
      asynchronous block cipher).  The advantages of skcipher include:
      
        - A much less confusing name, since none of these algorithm types have
          ever actually been for raw block ciphers, but rather for all
          length-preserving encryption modes including block cipher modes of
          operation, stream ciphers, and other length-preserving modes.
      
        - It unified blkcipher and ablkcipher into a single algorithm type
          which supports both synchronous and asynchronous implementations.
          Note, blkcipher already operated only on scatterlists, so the fact
          that skcipher does too isn't a regression in functionality.
      
        - Better type safety by using struct skcipher_alg, struct
          crypto_skcipher, etc. instead of crypto_alg, crypto_tfm, etc.
      
        - It sometimes simplifies the implementations of algorithms.
      
      Also, the blkcipher API was no longer being tested.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c65058b7
  10. 02 10月, 2019 1 次提交
    • F
      netfilter: drop bridge nf reset from nf_reset · 895b5c9f
      Florian Westphal 提交于
      commit 174e2381
      ("sk_buff: drop all skb extensions on free and skb scrubbing") made napi
      recycle always drop skb extensions.  The additional skb_ext_del() that is
      performed via nf_reset on napi skb recycle is not needed anymore.
      
      Most nf_reset() calls in the stack are there so queued skb won't block
      'rmmod nf_conntrack' indefinitely.
      
      This removes the skb_ext_del from nf_reset, and renames it to a more
      fitting nf_reset_ct().
      
      In a few selected places, add a call to skb_ext_reset to make sure that
      no active extensions remain.
      
      I am submitting this for "net", because we're still early in the release
      cycle.  The patch applies to net-next too, but I think the rename causes
      needless divergence between those trees.
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      895b5c9f
  11. 01 10月, 2019 1 次提交
  12. 25 8月, 2019 1 次提交
    • H
      xfrm/xfrm_policy: fix dst dev null pointer dereference in collect_md mode · c3b4c3a4
      Hangbin Liu 提交于
      In decode_session{4,6} there is a possibility that the skb dst dev is NULL,
      e,g, with tunnel collect_md mode, which will cause kernel crash.
      Here is what the code path looks like, for GRE:
      
      - ip6gre_tunnel_xmit
        - ip6gre_xmit_ipv6
          - __gre6_xmit
            - ip6_tnl_xmit
              - if skb->len - t->tun_hlen - eth_hlen > mtu; return -EMSGSIZE
          - icmpv6_send
            - icmpv6_route_lookup
              - xfrm_decode_session_reverse
                - decode_session4
                  - oif = skb_dst(skb)->dev->ifindex; <-- here
                - decode_session6
                  - oif = skb_dst(skb)->dev->ifindex; <-- here
      
      The reason is __metadata_dst_init() init dst->dev to NULL by default.
      We could not fix it in __metadata_dst_init() as there is no dev supplied.
      On the other hand, the skb_dst(skb)->dev is actually not needed as we
      called decode_session{4,6} via xfrm_decode_session_reverse(), so oif is not
      used by: fl4->flowi4_oif = reverse ? skb->skb_iif : oif;
      
      So make a dst dev check here should be clean and safe.
      
      v4: No changes.
      
      v3: No changes.
      
      v2: fix the issue in decode_session{4,6} instead of updating shared dst dev
      in {ip_md, ip6}_tunnel_xmit.
      
      Fixes: 8d79266b ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Tested-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3b4c3a4
  13. 20 8月, 2019 1 次提交
    • F
      xfrm: policy: avoid warning splat when merging nodes · 769a807d
      Florian Westphal 提交于
      syzbot reported a splat:
       xfrm_policy_inexact_list_reinsert+0x625/0x6e0 net/xfrm/xfrm_policy.c:877
       CPU: 1 PID: 6756 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #57
       Call Trace:
        xfrm_policy_inexact_node_reinsert net/xfrm/xfrm_policy.c:922 [inline]
        xfrm_policy_inexact_node_merge net/xfrm/xfrm_policy.c:958 [inline]
        xfrm_policy_inexact_insert_node+0x537/0xb50 net/xfrm/xfrm_policy.c:1023
        xfrm_policy_inexact_alloc_chain+0x62b/0xbd0 net/xfrm/xfrm_policy.c:1139
        xfrm_policy_inexact_insert+0xe8/0x1540 net/xfrm/xfrm_policy.c:1182
        xfrm_policy_insert+0xdf/0xce0 net/xfrm/xfrm_policy.c:1574
        xfrm_add_policy+0x4cf/0x9b0 net/xfrm/xfrm_user.c:1670
        xfrm_user_rcv_msg+0x46b/0x720 net/xfrm/xfrm_user.c:2676
        netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2477
        xfrm_netlink_rcv+0x74/0x90 net/xfrm/xfrm_user.c:2684
        netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
        netlink_unicast+0x809/0x9a0 net/netlink/af_netlink.c:1328
        netlink_sendmsg+0xa70/0xd30 net/netlink/af_netlink.c:1917
        sock_sendmsg_nosec net/socket.c:637 [inline]
        sock_sendmsg net/socket.c:657 [inline]
      
      There is no reproducer, however, the warning can be reproduced
      by adding rules with ever smaller prefixes.
      
      The sanity check ("does the policy match the node") uses the prefix value
      of the node before its updated to the smaller value.
      
      To fix this, update the prefix earlier.  The bug has no impact on tree
      correctness, this is only to prevent a false warning.
      
      Reported-by: syzbot+8cc27ace5f6972910b31@syzkaller.appspotmail.com
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      769a807d
  14. 31 7月, 2019 1 次提交
  15. 17 7月, 2019 4 次提交
  16. 03 7月, 2019 2 次提交
    • N
      xfrm interface: fix memory leak on creation · 56c5ee1a
      Nicolas Dichtel 提交于
      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>
      56c5ee1a
    • F
      xfrm: policy: fix bydst hlist corruption on hash rebuild · fd709721
      Florian Westphal 提交于
      syzbot reported following spat:
      
      BUG: KASAN: use-after-free in __write_once_size include/linux/compiler.h:221
      BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455
      BUG: KASAN: use-after-free in xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
      Write of size 8 at addr ffff888095e79c00 by task kworker/1:3/8066
      Workqueue: events xfrm_hash_rebuild
      Call Trace:
       __write_once_size include/linux/compiler.h:221 [inline]
       hlist_del_rcu include/linux/rculist.h:455 [inline]
       xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
       process_one_work+0x814/0x1130 kernel/workqueue.c:2269
      Allocated by task 8064:
       __kmalloc+0x23c/0x310 mm/slab.c:3669
       kzalloc include/linux/slab.h:742 [inline]
       xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
       xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
       xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
       ops_init+0x336/0x420 net/core/net_namespace.c:130
       setup_net+0x212/0x690 net/core/net_namespace.c:316
      
      The faulting address is the address of the old chain head,
      free'd by xfrm_hash_resize().
      
      In xfrm_hash_rehash(), chain heads get re-initialized without
      any hlist_del_rcu:
      
       for (i = hmask; i >= 0; i--)
          INIT_HLIST_HEAD(odst + i);
      
      Then, hlist_del_rcu() gets called on the about to-be-reinserted policy
      when iterating the per-net list of policies.
      
      hlist_del_rcu() will then make chain->first be nonzero again:
      
      static inline void __hlist_del(struct hlist_node *n)
      {
         struct hlist_node *next = n->next;   // address of next element in list
         struct hlist_node **pprev = n->pprev;// location of previous elem, this
                                              // can point at chain->first
              WRITE_ONCE(*pprev, next);       // chain->first points to next elem
              if (next)
                      next->pprev = pprev;
      
      Then, when we walk chainlist to find insertion point, we may find a
      non-empty list even though we're supposedly reinserting the first
      policy to an empty chain.
      
      To fix this first unlink all exact and inexact policies instead of
      zeroing the list heads.
      
      Add the commands equivalent to the syzbot reproducer to xfrm_policy.sh,
      without fix KASAN catches the corruption as it happens, SLUB poisoning
      detects it a bit later.
      
      Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com
      Fixes: 1548bc4e ("xfrm: policy: delete inexact policies from inexact list on hash rebuild")
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      fd709721
  17. 02 7月, 2019 1 次提交
  18. 01 7月, 2019 1 次提交
  19. 21 6月, 2019 1 次提交
  20. 17 6月, 2019 1 次提交
  21. 14 6月, 2019 1 次提交
  22. 12 6月, 2019 1 次提交
  23. 06 6月, 2019 3 次提交
  24. 05 6月, 2019 4 次提交
  25. 31 5月, 2019 1 次提交
  26. 28 5月, 2019 1 次提交
  27. 21 5月, 2019 2 次提交