1. 23 7月, 2020 1 次提交
  2. 20 7月, 2020 3 次提交
  3. 09 7月, 2020 1 次提交
  4. 29 6月, 2020 1 次提交
  5. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  6. 31 5月, 2020 2 次提交
    • E
      l2tp: add sk_family checks to l2tp_validate_socket · d9a81a22
      Eric Dumazet 提交于
      syzbot was able to trigger a crash after using an ISDN socket
      and fool l2tp.
      
      Fix this by making sure the UDP socket is of the proper family.
      
      BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78
      Write of size 1 at addr ffff88808ed0c590 by task syz-executor.5/3018
      
      CPU: 0 PID: 3018 Comm: syz-executor.5 Not tainted 5.7.0-rc6-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x188/0x20d lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:382
       __kasan_report.cold+0x20/0x38 mm/kasan/report.c:511
       kasan_report+0x33/0x50 mm/kasan/common.c:625
       setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78
       l2tp_tunnel_register+0xb15/0xdd0 net/l2tp/l2tp_core.c:1523
       l2tp_nl_cmd_tunnel_create+0x4b2/0xa60 net/l2tp/l2tp_netlink.c:249
       genl_family_rcv_msg_doit net/netlink/genetlink.c:673 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:718 [inline]
       genl_rcv_msg+0x627/0xdf0 net/netlink/genetlink.c:735
       netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:746
       netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
       netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329
       netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:672
       ____sys_sendmsg+0x6e6/0x810 net/socket.c:2352
       ___sys_sendmsg+0x100/0x170 net/socket.c:2406
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
       do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      RIP: 0033:0x45ca29
      Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007effe76edc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000004fe1c0 RCX: 000000000045ca29
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005
      RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 000000000000094e R14: 00000000004d5d00 R15: 00007effe76ee6d4
      
      Allocated by task 3018:
       save_stack+0x1b/0x40 mm/kasan/common.c:49
       set_track mm/kasan/common.c:57 [inline]
       __kasan_kmalloc mm/kasan/common.c:495 [inline]
       __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:468
       __do_kmalloc mm/slab.c:3656 [inline]
       __kmalloc+0x161/0x7a0 mm/slab.c:3665
       kmalloc include/linux/slab.h:560 [inline]
       sk_prot_alloc+0x223/0x2f0 net/core/sock.c:1612
       sk_alloc+0x36/0x1100 net/core/sock.c:1666
       data_sock_create drivers/isdn/mISDN/socket.c:600 [inline]
       mISDN_sock_create+0x272/0x400 drivers/isdn/mISDN/socket.c:796
       __sock_create+0x3cb/0x730 net/socket.c:1428
       sock_create net/socket.c:1479 [inline]
       __sys_socket+0xef/0x200 net/socket.c:1521
       __do_sys_socket net/socket.c:1530 [inline]
       __se_sys_socket net/socket.c:1528 [inline]
       __x64_sys_socket+0x6f/0xb0 net/socket.c:1528
       do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Freed by task 2484:
       save_stack+0x1b/0x40 mm/kasan/common.c:49
       set_track mm/kasan/common.c:57 [inline]
       kasan_set_free_info mm/kasan/common.c:317 [inline]
       __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:456
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x109/0x2b0 mm/slab.c:3757
       kvfree+0x42/0x50 mm/util.c:603
       __free_fdtable+0x2d/0x70 fs/file.c:31
       put_files_struct fs/file.c:420 [inline]
       put_files_struct+0x248/0x2e0 fs/file.c:413
       exit_files+0x7e/0xa0 fs/file.c:445
       do_exit+0xb04/0x2dd0 kernel/exit.c:791
       do_group_exit+0x125/0x340 kernel/exit.c:894
       get_signal+0x47b/0x24e0 kernel/signal.c:2739
       do_signal+0x81/0x2240 arch/x86/kernel/signal.c:784
       exit_to_usermode_loop+0x26c/0x360 arch/x86/entry/common.c:161
       prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
       do_syscall_64+0x6b1/0x7d0 arch/x86/entry/common.c:305
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      The buggy address belongs to the object at ffff88808ed0c000
       which belongs to the cache kmalloc-2k of size 2048
      The buggy address is located 1424 bytes inside of
       2048-byte region [ffff88808ed0c000, ffff88808ed0c800)
      The buggy address belongs to the page:
      page:ffffea00023b4300 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea0002838208 ffffea00015ba288 ffff8880aa000e00
      raw: 0000000000000000 ffff88808ed0c000 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88808ed0c480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff88808ed0c500: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88808ed0c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                               ^
       ffff88808ed0c600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88808ed0c680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Fixes: 6b9f3423 ("l2tp: fix races in tunnel creation")
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Cc: Guillaume Nault <gnault@redhat.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9a81a22
    • E
      l2tp: do not use inet_hash()/inet_unhash() · 02c71b14
      Eric Dumazet 提交于
      syzbot recently found a way to crash the kernel [1]
      
      Issue here is that inet_hash() & inet_unhash() are currently
      only meant to be used by TCP & DCCP, since only these protocols
      provide the needed hashinfo pointer.
      
      L2TP uses a single list (instead of a hash table)
      
      This old bug became an issue after commit 61023658
      ("bpf: Add new cgroup attach type to enable sock modifications")
      since after this commit, sk_common_release() can be called
      while the L2TP socket is still considered 'hashed'.
      
      general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
      CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
      Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
      RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
      RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
      RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
      R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
      R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
      FS:  0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       sk_common_release+0xba/0x370 net/core/sock.c:3210
       inet_create net/ipv4/af_inet.c:390 [inline]
       inet_create+0x966/0xe00 net/ipv4/af_inet.c:248
       __sock_create+0x3cb/0x730 net/socket.c:1428
       sock_create net/socket.c:1479 [inline]
       __sys_socket+0xef/0x200 net/socket.c:1521
       __do_sys_socket net/socket.c:1530 [inline]
       __se_sys_socket net/socket.c:1528 [inline]
       __x64_sys_socket+0x6f/0xb0 net/socket.c:1528
       do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      RIP: 0033:0x441e29
      Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 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 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29
      RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000
      Modules linked in:
      ---[ end trace 23b6578228ce553e ]---
      RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
      Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
      RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
      RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
      RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
      R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
      R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
      FS:  0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 0d76751f ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Cc: Andrii Nakryiko <andriin@fb.com>
      Reported-by: syzbot+3610d489778b57cc8031@syzkaller.appspotmail.com
      02c71b14
  7. 19 5月, 2020 1 次提交
  8. 05 5月, 2020 1 次提交
  9. 09 4月, 2020 1 次提交
    • M
      l2tp: Allow management of tunnels and session in user namespace · 2abe0523
      Michael Weiß 提交于
      Creation and management of L2TPv3 tunnels and session through netlink
      requires CAP_NET_ADMIN. However, a process with CAP_NET_ADMIN in a
      non-initial user namespace gets an EPERM due to the use of the
      genetlink GENL_ADMIN_PERM flag. Thus, management of L2TP VPNs inside
      an unprivileged container won't work.
      
      We replaced the GENL_ADMIN_PERM by the GENL_UNS_ADMIN_PERM flag
      similar to other network modules which also had this problem, e.g.,
      openvswitch (commit 4a92602a "openvswitch: allow management from
      inside user namespaces") and nl80211 (commit 5617c6cd "nl80211:
      Allow privileged operations from user namespaces").
      
      I tested this in the container runtime trustm3 (trustm3.github.io)
      and was able to create l2tp tunnels and sessions in unpriviliged
      (user namespaced) containers using a private network namespace.
      For other runtimes such as docker or lxc this should work, too.
      Signed-off-by: NMichael Weiß <michael.weiss@aisec.fraunhofer.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2abe0523
  10. 29 2月, 2020 1 次提交
    • G
      l2tp: Replace zero-length array with flexible-array member · af71b090
      Gustavo A. R. Silva 提交于
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      Lastly, fix the following checkpatch warning:
      CHECK: Prefer kernel type 'u8' over 'uint8_t'
      #50: FILE: net/l2tp/l2tp_core.h:119:
      +	uint8_t			priv[];	/* private data */
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af71b090
  11. 04 2月, 2020 1 次提交
    • R
      l2tp: Allow duplicate session creation with UDP · 0d0d9a38
      Ridge Kennedy 提交于
      In the past it was possible to create multiple L2TPv3 sessions with the
      same session id as long as the sessions belonged to different tunnels.
      The resulting sessions had issues when used with IP encapsulated tunnels,
      but worked fine with UDP encapsulated ones. Some applications began to
      rely on this behaviour to avoid having to negotiate unique session ids.
      
      Some time ago a change was made to require session ids to be unique across
      all tunnels, breaking the applications making use of this "feature".
      
      This change relaxes the duplicate session id check to allow duplicates
      if both of the colliding sessions belong to UDP encapsulated tunnels.
      
      Fixes: dbdbc73b ("l2tp: fix duplicate session creation")
      Signed-off-by: NRidge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
      Acked-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d0d9a38
  12. 04 1月, 2020 1 次提交
  13. 05 12月, 2019 1 次提交
  14. 25 10月, 2019 1 次提交
    • T
      net: core: add generic lockdep keys · ab92d68f
      Taehee Yoo 提交于
      Some interface types could be nested.
      (VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI, VXLAN, etc..)
      These interface types should set lockdep class because, without lockdep
      class key, lockdep always warn about unexisting circular locking.
      
      In the current code, these interfaces have their own lockdep class keys and
      these manage itself. So that there are so many duplicate code around the
      /driver/net and /net/.
      This patch adds new generic lockdep keys and some helper functions for it.
      
      This patch does below changes.
      a) Add lockdep class keys in struct net_device
         - qdisc_running, xmit, addr_list, qdisc_busylock
         - these keys are used as dynamic lockdep key.
      b) When net_device is being allocated, lockdep keys are registered.
         - alloc_netdev_mqs()
      c) When net_device is being free'd llockdep keys are unregistered.
         - free_netdev()
      d) Add generic lockdep key helper function
         - netdev_register_lockdep_key()
         - netdev_unregister_lockdep_key()
         - netdev_update_lockdep_key()
      e) Remove unnecessary generic lockdep macro and functions
      f) Remove unnecessary lockdep code of each interfaces.
      
      After this patch, each interface modules don't need to maintain
      their lockdep keys.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab92d68f
  15. 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
  16. 31 7月, 2019 1 次提交
    • A
      compat_ioctl: pppoe: fix PPPOEIOCSFWD handling · 055d8824
      Arnd Bergmann 提交于
      Support for handling the PPPOEIOCSFWD ioctl in compat mode was added in
      linux-2.5.69 along with hundreds of other commands, but was always broken
      sincen only the structure is compatible, but the command number is not,
      due to the size being sizeof(size_t), or at first sizeof(sizeof((struct
      sockaddr_pppox)), which is different on 64-bit architectures.
      
      Guillaume Nault adds:
      
        And the implementation was broken until 2016 (see 29e73269 ("pppoe:
        fix reference counting in PPPoE proxy")), and nobody ever noticed. I
        should probably have removed this ioctl entirely instead of fixing it.
        Clearly, it has never been used.
      
      Fix it by adding a compat_ioctl handler for all pppoe variants that
      translates the command number and then calls the regular ioctl function.
      
      All other ioctl commands handled by pppoe are compatible between 32-bit
      and 64-bit, and require compat_ptr() conversion.
      
      This should apply to all stable kernels.
      Acked-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      055d8824
  17. 09 7月, 2019 1 次提交
    • W
      ipv6: elide flowlabel check if no exclusive leases exist · 59c820b2
      Willem de Bruijn 提交于
      Processes can request ipv6 flowlabels with cmsg IPV6_FLOWINFO.
      If not set, by default an autogenerated flowlabel is selected.
      
      Explicit flowlabels require a control operation per label plus a
      datapath check on every connection (every datagram if unconnected).
      This is particularly expensive on unconnected sockets multiplexing
      many flows, such as QUIC.
      
      In the common case, where no lease is exclusive, the check can be
      safely elided, as both lease request and check trivially succeed.
      Indeed, autoflowlabel does the same even with exclusive leases.
      
      Elide the check if no process has requested an exclusive lease.
      
      fl6_sock_lookup previously returns either a reference to a lease or
      NULL to denote failure. Modify to return a real error and update
      all callers. On return NULL, they can use the label and will elide
      the atomic_dec in fl6_sock_release.
      
      This is an optimization. Robust applications still have to revert to
      requesting leases if the fast path fails due to an exclusive lease.
      
      Changes RFC->v1:
        - use static_key_false_deferred to rate limit jump label operations
          - call static_key_deferred_flush to stop timers on exit
        - move decrement out of RCU context
        - defer optimization also if opt data is associated with a lease
        - updated all fp6_sock_lookup callers, not just udp
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59c820b2
  18. 19 6月, 2019 1 次提交
  19. 14 6月, 2019 1 次提交
  20. 31 5月, 2019 1 次提交
  21. 21 5月, 2019 1 次提交
  22. 08 5月, 2019 1 次提交
    • Y
      l2tp: Fix possible NULL pointer dereference · 638a3a1e
      YueHaibing 提交于
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
      PGD 0 P4D 0
      Oops: 0000 [#1
      CPU: 0 PID: 5697 Comm: modprobe Tainted: G        W         5.1.0-rc7+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:__lock_acquire+0x53/0x10b0
      Code: 8b 1c 25 40 5e 01 00 4c 8b 6d 10 45 85 e4 0f 84 bd 06 00 00 44 8b 1d 7c d2 09 02 49 89 fe 41 89 d2 45 85 db 0f 84 47 02 00 00 <48> 81 3f a0 05 70 83 b8 00 00 00 00 44 0f 44 c0 83 fe 01 0f 86 3a
      RSP: 0018:ffffc90001c07a28 EFLAGS: 00010002
      RAX: 0000000000000000 RBX: ffff88822f038440 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000128
      RBP: ffffc90001c07a88 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
      R13: 0000000000000000 R14: 0000000000000128 R15: 0000000000000000
      FS:  00007fead0811540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000128 CR3: 00000002310da000 CR4: 00000000000006f0
      Call Trace:
       ? __lock_acquire+0x24e/0x10b0
       lock_acquire+0xdf/0x230
       ? flush_workqueue+0x71/0x530
       flush_workqueue+0x97/0x530
       ? flush_workqueue+0x71/0x530
       l2tp_exit_net+0x170/0x2b0 [l2tp_core
       ? l2tp_exit_net+0x93/0x2b0 [l2tp_core
       ops_exit_list.isra.6+0x36/0x60
       unregister_pernet_operations+0xb8/0x110
       unregister_pernet_device+0x25/0x40
       l2tp_init+0x55/0x1000 [l2tp_core
       ? 0xffffffffa018d000
       do_one_initcall+0x6c/0x3cc
       ? do_init_module+0x22/0x1f1
       ? rcu_read_lock_sched_held+0x97/0xb0
       ? kmem_cache_alloc_trace+0x325/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7fead031a839
      Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffe8d9acca8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 0000560078398b80 RCX: 00007fead031a839
      RDX: 0000000000000000 RSI: 000056007659dc2e RDI: 0000000000000003
      RBP: 000056007659dc2e R08: 0000000000000000 R09: 0000560078398b80
      R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
      R13: 00005600783a04a0 R14: 0000000000040000 R15: 0000560078398b80
      Modules linked in: l2tp_core(+) e1000 ip_tables ipv6 [last unloaded: l2tp_core
      CR2: 0000000000000128
      ---[ end trace 8322b2b8bf83f8e1
      
      If alloc_workqueue fails in l2tp_init, l2tp_net_ops
      is unregistered on failure path. Then l2tp_exit_net
      is called which will flush NULL workqueue, this patch
      add a NULL check to fix it.
      
      Fixes: 67e04c29 ("l2tp: unregister l2tp_net_ops on failure path")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      638a3a1e
  23. 30 4月, 2019 1 次提交
    • E
      l2ip: fix possible use-after-free · a622b400
      Eric Dumazet 提交于
      Before taking a refcount on a rcu protected structure,
      we need to make sure the refcount is not zero.
      
      syzbot reported :
      
      refcount_t: increment on 0; use-after-free.
      WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked lib/refcount.c:156 [inline]
      WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked+0x61/0x70 lib/refcount.c:154
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 1 PID: 23533 Comm: syz-executor.2 Not tainted 5.1.0-rc7+ #93
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       panic+0x2cb/0x65c kernel/panic.c:214
       __warn.cold+0x20/0x45 kernel/panic.c:571
       report_bug+0x263/0x2b0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:179 [inline]
       fixup_bug arch/x86/kernel/traps.c:174 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
       do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
      RIP: 0010:refcount_inc_checked lib/refcount.c:156 [inline]
      RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:154
      Code: 1d 98 2b 2a 06 31 ff 89 de e8 db 2c 40 fe 84 db 75 dd e8 92 2b 40 fe 48 c7 c7 20 7a a1 87 c6 05 78 2b 2a 06 01 e8 7d d9 12 fe <0f> 0b eb c1 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41
      RSP: 0018:ffff888069f0fba8 EFLAGS: 00010286
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 000000000000f353 RSI: ffffffff815afcb6 RDI: ffffed100d3e1f67
      RBP: ffff888069f0fbb8 R08: ffff88809b1845c0 R09: ffffed1015d23ef1
      R10: ffffed1015d23ef0 R11: ffff8880ae91f787 R12: ffff8880a8f26968
      R13: 0000000000000004 R14: dffffc0000000000 R15: ffff8880a49a6440
       l2tp_tunnel_inc_refcount net/l2tp/l2tp_core.h:240 [inline]
       l2tp_tunnel_get+0x250/0x580 net/l2tp/l2tp_core.c:173
       pppol2tp_connect+0xc00/0x1c70 net/l2tp/l2tp_ppp.c:702
       __sys_connect+0x266/0x330 net/socket.c:1808
       __do_sys_connect net/socket.c:1819 [inline]
       __se_sys_connect net/socket.c:1816 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1816
      
      Fixes: 54652eb1 ("l2tp: hold tunnel while looking up sessions in l2tp_netlink")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Guillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a622b400
  24. 28 4月, 2019 2 次提交
    • J
      genetlink: optionally validate strictly/dumps · ef6243ac
      Johannes Berg 提交于
      Add options to strictly validate messages and dump messages,
      sometimes perhaps validating dump messages non-strictly may
      be required, so add an option for that as well.
      
      Since none of this can really be applied to existing commands,
      set the options everwhere using the following spatch:
      
          @@
          identifier ops;
          expression X;
          @@
          struct genl_ops ops[] = {
          ...,
           {
                  .cmd = X,
          +       .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
                  ...
           },
          ...
          };
      
      For new commands one should just not copy the .validate 'opt-out'
      flags and thus get strict validation.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef6243ac
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  25. 26 4月, 2019 1 次提交
  26. 20 4月, 2019 1 次提交
  27. 19 4月, 2019 1 次提交
  28. 22 3月, 2019 1 次提交
    • J
      genetlink: make policy common to family · 3b0f31f2
      Johannes Berg 提交于
      Since maxattr is common, the policy can't really differ sanely,
      so make it common as well.
      
      The only user that did in fact manage to make a non-common policy
      is taskstats, which has to be really careful about it (since it's
      still using a common maxattr!). This is no longer supported, but
      we can fake it using pre_doit.
      
      This reduces the size of e.g. nl80211.o (which has lots of commands):
      
         text	   data	    bss	    dec	    hex	filename
       398745	  14323	   2240	 415308	  6564c	net/wireless/nl80211.o (before)
       397913	  14331	   2240	 414484	  65314	net/wireless/nl80211.o (after)
      --------------------------------
         -832      +8       0    -824
      
      Which is obviously just 8 bytes for each command, and an added 8
      bytes for the new policy pointer. I'm not sure why the ops list is
      counted as .text though.
      
      Most of the code transformations were done using the following spatch:
          @ops@
          identifier OPS;
          expression POLICY;
          @@
          struct genl_ops OPS[] = {
          ...,
           {
          -	.policy = POLICY,
           },
          ...
          };
      
          @@
          identifier ops.OPS;
          expression ops.POLICY;
          identifier fam;
          expression M;
          @@
          struct genl_family fam = {
                  .ops = OPS,
                  .maxattr = M,
          +       .policy = POLICY,
                  ...
          };
      
      This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
      the cb->data as ops, which we want to change in a later genl patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b0f31f2
  29. 14 3月, 2019 1 次提交
    • E
      l2tp: fix infoleak in l2tp_ip6_recvmsg() · 163d1c3d
      Eric Dumazet 提交于
      Back in 2013 Hannes took care of most of such leaks in commit
      bceaa902 ("inet: prevent leakage of uninitialized memory to user in recv syscalls")
      
      But the bug in l2tp_ip6_recvmsg() has not been fixed.
      
      syzbot report :
      
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      CPU: 1 PID: 10996 Comm: syz-executor362 Not tainted 5.0.0+ #11
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600
       kmsan_internal_check_memory+0x9f4/0xb10 mm/kmsan/kmsan.c:694
       kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
       _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
       copy_to_user include/linux/uaccess.h:174 [inline]
       move_addr_to_user+0x311/0x570 net/socket.c:227
       ___sys_recvmsg+0xb65/0x1310 net/socket.c:2283
       do_recvmmsg+0x646/0x10c0 net/socket.c:2390
       __sys_recvmmsg net/socket.c:2469 [inline]
       __do_sys_recvmmsg net/socket.c:2492 [inline]
       __se_sys_recvmmsg+0x1d1/0x350 net/socket.c:2485
       __x64_sys_recvmmsg+0x62/0x80 net/socket.c:2485
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x445819
      Code: e8 6c b6 02 00 48 83 c4 18 c3 0f 1f 80 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 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f64453eddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445819
      RDX: 0000000000000005 RSI: 0000000020002f80 RDI: 0000000000000003
      RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c
      R13: 00007ffeba8f87af R14: 00007f64453ee9c0 R15: 20c49ba5e353f7cf
      
      Local variable description: ----addr@___sys_recvmsg
      Variable was created at:
       ___sys_recvmsg+0xf6/0x1310 net/socket.c:2244
       do_recvmmsg+0x646/0x10c0 net/socket.c:2390
      
      Bytes 0-31 of 32 are uninitialized
      Memory access of size 32 starts at ffff8880ae62fbb0
      Data copied to user address 0000000020000000
      
      Fixes: a32e0eec ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      163d1c3d
  30. 01 2月, 2019 1 次提交
  31. 31 1月, 2019 1 次提交
    • J
      l2tp: fix reading optional fields of L2TPv3 · 4522a70d
      Jacob Wen 提交于
      Use pskb_may_pull() to make sure the optional fields are in skb linear
      parts, so we can safely read them later.
      
      It's easy to reproduce the issue with a net driver that supports paged
      skb data. Just create a L2TPv3 over IP tunnel and then generates some
      network traffic.
      Once reproduced, rx err in /sys/kernel/debug/l2tp/tunnels will increase.
      
      Changes in v4:
      1. s/l2tp_v3_pull_opt/l2tp_v3_ensure_opt_in_linear/
      2. s/tunnel->version != L2TP_HDR_VER_2/tunnel->version == L2TP_HDR_VER_3/
      3. Add 'Fixes' in commit messages.
      
      Changes in v3:
      1. To keep consistency, move the code out of l2tp_recv_common.
      2. Use "net" instead of "net-next", since this is a bug fix.
      
      Changes in v2:
      1. Only fix L2TPv3 to make code simple.
         To fix both L2TPv3 and L2TPv2, we'd better refactor l2tp_recv_common.
         It's complicated to do so.
      2. Reloading pointers after pskb_may_pull
      
      Fixes: f7faffa3 ("l2tp: Add L2TPv3 protocol support")
      Fixes: 0d76751f ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
      Fixes: a32e0eec ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
      Signed-off-by: NJacob Wen <jian.w.wen@oracle.com>
      Acked-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4522a70d
  32. 21 12月, 2018 1 次提交
    • S
      ppp: Move PFC decompression to PPP generic layer · 7fb1b8ca
      Sam Protsenko 提交于
      Extract "Protocol" field decompression code from transport protocols to
      PPP generic layer, where it actually belongs. As a consequence, this
      patch fixes incorrect place of PFC decompression in L2TP driver (when
      it's not PPPOX_BOUND) and also enables this decompression for other
      protocols, like PPPoE.
      
      Protocol field decompression also happens in PPP Multilink Protocol
      code and in PPP compression protocols implementations (bsd, deflate,
      mppe). It looks like there is no easy way to get rid of that, so it was
      decided to leave it as is, but provide those cases with appropriate
      comments instead.
      
      Changes in v2:
        - Fix the order of checking skb data room and proto decompression
        - Remove "inline" keyword from ppp_decompress_proto()
        - Don't split line before function name
        - Prefix ppp_decompress_proto() function with "__"
        - Add ppp_decompress_proto() function with skb data room checks
        - Add description for introduced functions
        - Fix comments (as per review on mailing list)
      Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
      Reviewed-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fb1b8ca
  33. 16 12月, 2018 1 次提交
    • S
      l2tp: Add protocol field decompression · c151acc6
      Sam Protsenko 提交于
      When Protocol Field Compression (PFC) is enabled, the "Protocol" field
      in PPP packet will be received without leading 0x00. See section 6.5 in
      RFC 1661 for details. So let's decompress protocol field if needed, the
      same way it's done in drivers/net/ppp/pptp.c.
      
      In case when "nopcomp" pppd option is not enabled, PFC (pcomp) can be
      negotiated during LCP handshake, and L2TP driver in kernel will receive
      PPP packets with compressed Protocol field, which in turn leads to next
      error:
      
          Protocol Rejected (unsupported protocol 0x2145)
      
      because instead of Protocol=0x0021 in PPP packet there will be
      Protocol=0x21. This patch unwraps it back to 0x0021, which fixes the
      issue.
      
      Sending the compressed Protocol field will be implemented in subsequent
      patch, this one is self-sufficient.
      Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c151acc6
  34. 15 11月, 2018 1 次提交
  35. 14 8月, 2018 1 次提交
    • A
      l2tp: fix unused function warning · c2ebc256
      Arnd Bergmann 提交于
      Removing one of the callers of pppol2tp_session_get_sock caused a harmless
      warning in some configurations:
      
      net/l2tp/l2tp_ppp.c:142:21: 'pppol2tp_session_get_sock' defined but not used [-Wunused-function]
      
      Rather than adding another #ifdef here, using a proper IS_ENABLED()
      check makes the code more readable and avoids those warnings while
      letting the compiler figure out for itself which code is needed.
      
      This adds one pointer for the unused show() callback in struct
      l2tp_session, but that seems harmless.
      
      Fixes: b0e29063 ("l2tp: remove pppol2tp_session_ioctl()")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2ebc256
  36. 13 8月, 2018 1 次提交
    • W
      l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache · 6d37fa49
      Wei Wang 提交于
      In l2tp code, if it is a L2TP_UDP_ENCAP tunnel, tunnel->sk points to a
      UDP socket. User could call sendmsg() on both this tunnel and the UDP
      socket itself concurrently. As l2tp_xmit_skb() holds socket lock and call
      __sk_dst_check() to refresh sk->sk_dst_cache, while udpv6_sendmsg() is
      lockless and call sk_dst_check() to refresh sk->sk_dst_cache, there
      could be a race and cause the dst cache to be freed multiple times.
      So we fix l2tp side code to always call sk_dst_check() to garantee
      xchg() is called when refreshing sk->sk_dst_cache to avoid race
      conditions.
      
      Syzkaller reported stack trace:
      BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
      BUG: KASAN: use-after-free in atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
      BUG: KASAN: use-after-free in atomic_add_unless include/linux/atomic.h:597 [inline]
      BUG: KASAN: use-after-free in dst_hold_safe include/net/dst.h:308 [inline]
      BUG: KASAN: use-after-free in ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029
      Read of size 4 at addr ffff8801aea9a880 by task syz-executor129/4829
      
      CPU: 0 PID: 4829 Comm: syz-executor129 Not tainted 4.18.0-rc7-next-20180802+ #30
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
       atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
       atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
       atomic_add_unless include/linux/atomic.h:597 [inline]
       dst_hold_safe include/net/dst.h:308 [inline]
       ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029
       rt6_get_pcpu_route net/ipv6/route.c:1249 [inline]
       ip6_pol_route+0x354/0xd20 net/ipv6/route.c:1922
       ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2098
       fib6_rule_lookup+0x283/0x890 net/ipv6/fib6_rules.c:122
       ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:2126
       ip6_dst_lookup_tail+0x1278/0x1da0 net/ipv6/ip6_output.c:978
       ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1079
       ip6_sk_dst_lookup_flow+0x5ed/0xc50 net/ipv6/ip6_output.c:1117
       udpv6_sendmsg+0x2163/0x36b0 net/ipv6/udp.c:1354
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:632
       ___sys_sendmsg+0x51d/0x930 net/socket.c:2115
       __sys_sendmmsg+0x240/0x6f0 net/socket.c:2210
       __do_sys_sendmmsg net/socket.c:2239 [inline]
       __se_sys_sendmmsg net/socket.c:2236 [inline]
       __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2236
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x446a29
      Code: e8 ac b8 02 00 48 83 c4 18 c3 0f 1f 80 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 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f4de5532db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 00000000006dcc38 RCX: 0000000000446a29
      RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003
      RBP: 00000000006dcc30 R08: 00007f4de5533700 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dcc3c
      R13: 00007ffe2b830fdf R14: 00007f4de55339c0 R15: 0000000000000001
      
      Fixes: 71b1391a ("l2tp: ensure sk->dst is still valid")
      Reported-by: syzbot+05f840f3b04f211bad55@syzkaller.appspotmail.com
      Signed-off-by: NWei Wang <weiwan@google.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Cc: Guillaume Nault <g.nault@alphalink.fr>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d37fa49