1. 19 Mar, 2019 1 commit
    • Eric Dumazet's avatar
      l2tp: fix infoleak in l2tp_ip6_recvmsg() · af6822a7
      Eric Dumazet authored
      [ Upstream commit 163d1c3d6f17556ed3c340d3789ea93be95d6c28 ]
      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
      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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 06 Feb, 2019 3 commits
  3. 04 Nov, 2018 1 commit
    • James Chapman's avatar
      l2tp: remove configurable payload offset · 5c097f55
      James Chapman authored
      [ Upstream commit 900631ee ]
      If L2TP_ATTR_OFFSET is set to a non-zero value in L2TPv3 tunnels, it
      results in L2TPv3 packets being transmitted which might not be
      compliant with the L2TPv3 RFC. This patch has l2tp ignore the offset
      setting and send all packets with no offset.
      In more detail:
      L2TPv2 supports a variable offset from the L2TPv2 header to the
      payload. The offset value is indicated by an optional field in the
      L2TP header.  Our L2TP implementation already detects the presence of
      the optional offset and skips that many bytes when handling data
      received packets. All transmitted packets are always transmitted with
      no offset.
      L2TPv3 has no optional offset field in the L2TPv3 packet
      header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific
      Sublayer". At the time when the original L2TP code was written, there
      was talk at IETF of offset being implemented in a new Layer-2 Specific
      Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this
      offset could be configured and the intention was to allow it to be
      also used to set the tx offset for L2TPv2. However, no L2TPv3 offset
      was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten
      Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted
      with the specified number of bytes padding between L2TPv3 header and
      payload. This is not compliant with L2TPv3 RFC3931. This change
      removes the configurable offset altogether while retaining
      L2TP_ATTR_OFFSET for backwards compatibility. Any L2TP_ATTR_OFFSET
      value is ignored.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  4. 22 Aug, 2018 1 commit
    • Wei Wang's avatar
      l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache · 46be8e44
      Wei Wang authored
      [ Upstream commit 6d37fa49 ]
      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
      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
      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: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarMartin 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: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 19 May, 2018 1 commit
  6. 29 Apr, 2018 1 commit
  7. 12 Apr, 2018 1 commit
  8. 08 Apr, 2018 1 commit
    • Paolo Abeni's avatar
      l2tp: fix races with ipv4-mapped ipv6 addresses · b0850604
      Paolo Abeni authored
      commit b954f940 upstream.
      The l2tp_tunnel_create() function checks for v4mapped ipv6
      sockets and cache that flag, so that l2tp core code can
      reusing it at xmit time.
      If the socket is provided by the userspace, the connection
      status of the tunnel sockets can change between the tunnel
      creation and the xmit call, so that syzbot is able to
      trigger the following splat:
      BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:192
      BUG: KASAN: use-after-free in ip6_xmit+0x1f76/0x2260
      Read of size 8 at addr ffff8801bd949318 by task syz-executor4/23448
      CPU: 0 PID: 23448 Comm: syz-executor4 Not tainted 4.16.0-rc4+ #65
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:17 [inline]
        dump_stack+0x194/0x24d lib/dump_stack.c:53
        print_address_description+0x73/0x250 mm/kasan/report.c:256
        kasan_report_error mm/kasan/report.c:354 [inline]
        kasan_report+0x23c/0x360 mm/kasan/report.c:412
        __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
        ip6_dst_idev include/net/ip6_fib.h:192 [inline]
        ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
        inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
        l2tp_xmit_core net/l2tp/l2tp_core.c:1053 [inline]
        l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1148
        pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg+0xca/0x110 net/socket.c:640
        ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
        __sys_sendmsg+0xe5/0x210 net/socket.c:2080
        SYSC_sendmsg net/socket.c:2091 [inline]
        SyS_sendmsg+0x2d/0x50 net/socket.c:2087
        do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
      RIP: 0033:0x453e69
      RSP: 002b:00007f819593cc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f819593d6d4 RCX: 0000000000453e69
      RDX: 0000000000000081 RSI: 000000002037ffc8 RDI: 0000000000000004
      RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000000004c3 R14: 00000000006f72e8 R15: 0000000000000000
      This change addresses the issues:
      * explicitly checking for TCP_ESTABLISHED for user space provided sockets
      * dropping the v4mapped flag usage - it can become outdated - and
        explicitly invoking ipv6_addr_v4mapped() instead
      The issue is apparently there since ancient times.
      v1 -> v2: (many thanks to Guillaume)
       - with csum issue introduced in v1
       - replace pr_err with pr_debug
       - fix build issue with IPV6 disabled
       - move l2tp_sk_is_v4mapped in l2tp_core.c
      v2 -> v3:
       - don't update inet_daddr for v4mapped address, unneeded
       - drop rendundant check at creation time
      Reported-and-tested-by: syzbot+92fa328176eb07e4ac1a@syzkaller.appspotmail.com
      Fixes: 3557baab ("[L2TP]: PPP over L2TP driver core")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 31 Mar, 2018 1 commit
    • Eric Dumazet's avatar
      l2tp: do not accept arbitrary sockets · 2d5b0ed0
      Eric Dumazet authored
      [ Upstream commit 17cfe79a ]
      syzkaller found an issue caused by lack of sufficient checks
      in l2tp_tunnel_create()
      RAW sockets can not be considered as UDP ones for instance.
      In another patch, we shall replace all pr_err() by less intrusive
      pr_debug() so that syzkaller can find other bugs faster.
      Acked-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Acked-by: default avatarJames Chapman <jchapman@katalix.com>
      BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
      dst_release: dst:00000000d53d0d0f refcnt:-1
      Write of size 1 at addr ffff8801d013b798 by task syz-executor3/6242
      CPU: 1 PID: 6242 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #253
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x24d lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report+0x23b/0x360 mm/kasan/report.c:412
       __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
       setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
       l2tp_tunnel_create+0x1354/0x17f0 net/l2tp/l2tp_core.c:1596
       pppol2tp_connect+0x14b1/0x1dd0 net/l2tp/l2tp_ppp.c:707
       SYSC_connect+0x213/0x4a0 net/socket.c:1640
       SyS_connect+0x24/0x30 net/socket.c:1621
       do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 20 Dec, 2017 1 commit
  11. 05 Nov, 2017 1 commit
    • Guillaume Nault's avatar
      l2tp: don't use l2tp_tunnel_find() in l2tp_ip and l2tp_ip6 · 8f7dc9ae
      Guillaume Nault authored
      Using l2tp_tunnel_find() in l2tp_ip_recv() is wrong for two reasons:
        * It doesn't take a reference on the returned tunnel, which makes the
          call racy wrt. concurrent tunnel deletion.
        * The lookup is only based on the tunnel identifier, so it can return
          a tunnel that doesn't match the packet's addresses or protocol.
      For example, a packet sent to an L2TPv3 over IPv6 tunnel can be
      delivered to an L2TPv2 over UDPv4 tunnel. This is worse than a simple
      cross-talk: when delivering the packet to an L2TP over UDP tunnel, the
      corresponding socket is UDP, where ->sk_backlog_rcv() is NULL. Calling
      sk_receive_skb() will then crash the kernel by trying to execute this
      And l2tp_tunnel_find() isn't even needed here. __l2tp_ip_bind_lookup()
      properly checks the socket binding and connection settings. It was used
      as a fallback mechanism for finding tunnels that didn't have their data
      path registered yet. But it's not limited to this case and can be used
      to replace l2tp_tunnel_find() in the general case.
      Fix l2tp_ip6 in the same way.
      Fixes: 0d76751f ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
      Fixes: a32e0eec ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  12. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
      All documentation files were explicitly excluded.
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
         For non */uapi/* files that summary was:
         SPDX license identifier                            # files
         GPL-2.0                                              11139
         and resulted in the first patch in this series.
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                        930
         and resulted in the second patch in this series.
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
         and that resulted in the third patch in this series.
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. 31 Oct, 2017 1 commit
  14. 15 Oct, 2017 1 commit
  15. 02 Oct, 2017 1 commit
  16. 26 Sep, 2017 1 commit
    • Sabrina Dubroca's avatar
      l2tp: fix race condition in l2tp_tunnel_delete · 62b982ee
      Sabrina Dubroca authored
      If we try to delete the same tunnel twice, the first delete operation
      does a lookup (l2tp_tunnel_get), finds the tunnel, calls
      l2tp_tunnel_delete, which queues it for deletion by
      The second delete operation also finds the tunnel and calls
      l2tp_tunnel_delete. If the workqueue has already fired and started
      running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the
      same tunnel a second time, and try to free the socket again.
      Add a dead flag to prevent firing the workqueue twice. Then we can
      remove the check of queue_work's result that was meant to prevent that
      race but doesn't.
          ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local remote encap udp udp_sport 5000 udp_dport 6000
          ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000
          ip link set l2tp1 up
          ip l2tp del tunnel tunnel_id 3000
          ip l2tp del tunnel tunnel_id 3000
      Fixes: f8ccac0e ("l2tp: put tunnel socket release on a workqueue")
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  17. 25 Sep, 2017 2 commits
    • Guillaume Nault's avatar
      l2tp: fix race between l2tp_session_delete() and l2tp_tunnel_closeall() · b228a940
      Guillaume Nault authored
      There are several ways to remove L2TP sessions:
        * deleting a session explicitly using the netlink interface (with
        * deleting the session's parent tunnel (either by closing the
          tunnel's file descriptor or using the netlink interface),
        * closing the PPPOL2TP file descriptor of a PPP pseudo-wire.
      In some cases, when these methods are used concurrently on the same
      session, the session can be removed twice, leading to use-after-free
      This patch adds a 'dead' flag, used by l2tp_session_delete() and
      l2tp_tunnel_closeall() to prevent them from stepping on each other's
      The session deletion path used when closing a PPPOL2TP file descriptor
      doesn't need to be adapted. It already has to ensure that a session
      remains valid for the lifetime of its PPPOL2TP file descriptor.
      So it takes an extra reference on the session in the ->session_close()
      callback (pppol2tp_session_close()), which is eventually dropped
      in the ->sk_destruct() callback of the PPPOL2TP socket
      Still, __l2tp_session_unhash() and l2tp_session_queue_purge() can be
      called twice and even concurrently for a given session, but thanks to
      proper locking and re-initialisation of list fields, this is not an
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Guillaume Nault's avatar
      l2tp: ensure sessions are freed after their PPPOL2TP socket · cdd10c96
      Guillaume Nault authored
      If l2tp_tunnel_delete() or l2tp_tunnel_closeall() deletes a session
      right after pppol2tp_release() orphaned its socket, then the 'sock'
      variable of the pppol2tp_session_close() callback is NULL. Yet the
      session is still used by pppol2tp_release().
      Therefore we need to take an extra reference in any case, to prevent
      l2tp_tunnel_delete() or l2tp_tunnel_closeall() from freeing the session.
      Since the pppol2tp_session_close() callback is only set if the session
      is associated to a PPPOL2TP socket and that both l2tp_tunnel_delete()
      and l2tp_tunnel_closeall() hold the PPPOL2TP socket before calling
      pppol2tp_session_close(), we're sure that pppol2tp_session_close() and
      pppol2tp_session_destruct() are paired and called in the right order.
      So the reference taken by the former will be released by the later.
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  18. 03 Sep, 2017 2 commits
    • Guillaume Nault's avatar
      l2tp: pass tunnel pointer to ->session_create() · f026bc29
      Guillaume Nault authored
      Using l2tp_tunnel_find() in pppol2tp_session_create() and
      l2tp_eth_create() is racy, because no reference is held on the
      returned session. These functions are only used to implement the
      ->session_create callback which is run by l2tp_nl_cmd_session_create().
      Therefore searching for the parent tunnel isn't necessary because
      l2tp_nl_cmd_session_create() already has a pointer to it and holds a
      This patch modifies ->session_create()'s prototype to directly pass the
      the parent tunnel as parameter, thus avoiding searching for it in
      pppol2tp_session_create() and l2tp_eth_create().
      Since we have to touch the ->session_create() call in
      l2tp_nl_cmd_session_create(), let's also remove the useless conditional:
      we know that ->session_create isn't NULL at this point because it's
      already been checked earlier in this same function.
      Finally, one might be tempted to think that the removed
      l2tp_tunnel_find() calls were harmless because they would return the
      same tunnel as the one held by l2tp_nl_cmd_session_create() anyway.
      But that tunnel might be removed and a new one created with same tunnel
      Id before the l2tp_tunnel_find() call. In this case l2tp_tunnel_find()
      would return the new tunnel which wouldn't be protected by the
      reference held by l2tp_nl_cmd_session_create().
      Fixes: 309795f4 ("l2tp: Add netlink control API for L2TP")
      Fixes: d9e31d17 ("l2tp: Add L2TP ethernet pseudowire support")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Guillaume Nault's avatar
      l2tp: prevent creation of sessions on terminated tunnels · f3c66d4e
      Guillaume Nault authored
      l2tp_tunnel_destruct() sets tunnel->sock to NULL, then removes the
      tunnel from the pernet list and finally closes all its sessions.
      Therefore, it's possible to add a session to a tunnel that is still
      reachable, but for which tunnel->sock has already been reset. This can
      make l2tp_session_create() dereference a NULL pointer when calling
      This patch adds the .acpt_newsess field to struct l2tp_tunnel, which is
      used by l2tp_tunnel_closeall() to prevent addition of new sessions to
      tunnels. Resetting tunnel->sock is done after l2tp_tunnel_closeall()
      returned, so that l2tp_session_add_to_tunnel() can safely take a
      reference on it when .acpt_newsess is true.
      The .acpt_newsess field is modified in l2tp_tunnel_closeall(), rather
      than in l2tp_tunnel_destruct(), so that it benefits all tunnel removal
      mechanisms. E.g. on UDP tunnels, a session could be added to a tunnel
      after l2tp_udp_encap_destroy() proceeded. This would prevent the tunnel
      from being removed because of the references held by this new session
      on the tunnel and its socket. Even though the session could be removed
      manually later on, this defeats the purpose of
      commit 9980d001 ("l2tp: add udp encap socket destroy handler").
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  19. 28 Aug, 2017 6 commits
  20. 01 Aug, 2017 1 commit
  21. 29 Jul, 2017 1 commit
  22. 04 Jul, 2017 2 commits
  23. 01 Jul, 2017 1 commit
  24. 10 Jun, 2017 1 commit
  25. 07 Jun, 2017 1 commit
    • David S. Miller's avatar
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller authored
      Network devices can allocate reasources and private memory using
      netdev_ops->ndo_init().  However, the release of these resources
      can occur in one of two different places.
      Either netdev_ops->ndo_uninit() or netdev->destructor().
      The decision of which operation frees the resources depends upon
      whether it is necessary for all netdev refs to be released before it
      is safe to perform the freeing.
      netdev_ops->ndo_uninit() presumably can occur right after the
      NETDEV_UNREGISTER notifier completes and the unicast and multicast
      address lists are flushed.
      netdev->destructor(), on the other hand, does not run until the
      netdev references all go away.
      Further complicating the situation is that netdev->destructor()
      almost universally does also a free_netdev().
      This creates a problem for the logic in register_netdevice().
      Because all callers of register_netdevice() manage the freeing
      of the netdev, and invoke free_netdev(dev) if register_netdevice()
      If netdev_ops->ndo_init() succeeds, but something else fails inside
      of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
      it is not able to invoke netdev->destructor().
      This is because netdev->destructor() will do a free_netdev() and
      then the caller of register_netdevice() will do the same.
      However, this means that the resources that would normally be released
      by netdev->destructor() will not be.
      Over the years drivers have added local hacks to deal with this, by
      invoking their destructor parts by hand when register_netdevice()
      Many drivers do not try to deal with this, and instead we have leaks.
      Let's close this hole by formalizing the distinction between what
      private things need to be freed up by netdev->destructor() and whether
      the driver needs unregister_netdevice() to perform the free_netdev().
      netdev->priv_destructor() performs all actions to free up the private
      resources that used to be freed by netdev->destructor(), except for
      netdev->needs_free_netdev is a boolean that indicates whether
      free_netdev() should be done at the end of unregister_netdevice().
      Now, register_netdevice() can sanely release all resources after
      ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
      and netdev->priv_destructor().
      And at the end of unregister_netdevice(), we invoke
      netdev->priv_destructor() and optionally call free_netdev().
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  26. 27 Apr, 2017 1 commit
  27. 25 Apr, 2017 2 commits
  28. 17 Apr, 2017 1 commit
  29. 12 Apr, 2017 1 commit