1. 31 7月, 2020 2 次提交
    • T
      l2tp: don't export tunnel and session free functions · 52016e25
      Tom Parkin 提交于
      Tunnel and session instances are reference counted, and shouldn't be
      directly freed by pseudowire code.
      
      Rather than exporting l2tp_tunnel_free and l2tp_session_free, make them
      private to l2tp_core.c, and export the refcount functions instead.
      
      In order to do this, the refcount functions cannot be declared as
      inline.  Since the codepaths which take and drop tunnel and session
      references are not directly in the datapath this shouldn't cause
      performance issues.
      Signed-off-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52016e25
    • T
      l2tp: don't export __l2tp_session_unhash · b2aecfe8
      Tom Parkin 提交于
      When __l2tp_session_unhash was first added it was used outside of
      l2tp_core.c, but that's no longer the case.
      
      As such, there's no longer a need to export the function.  Make it
      private inside l2tp_core.c, and relocate it to avoid having to declare
      the function prototype in l2tp_core.h.
      
      Since the function is no longer used outside l2tp_core.c, remove the
      "__" prefix since we don't need to indicate anything special about its
      expected use to callers.
      Signed-off-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2aecfe8
  2. 25 7月, 2020 10 次提交
  3. 24 7月, 2020 6 次提交
  4. 23 7月, 2020 10 次提交
  5. 20 7月, 2020 3 次提交
  6. 09 7月, 2020 1 次提交
  7. 29 6月, 2020 1 次提交
  8. 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
  9. 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
  10. 19 5月, 2020 1 次提交
  11. 05 5月, 2020 1 次提交
  12. 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
  13. 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