1. 19 Jan, 2018 2 commits
    • Wei Wang's avatar
      ipv6: don't let tb6_root node share routes with other node · 591ff9ea
      Wei Wang authored
      After commit 4512c43e, if we add a route to the subtree of tb6_root
      which does not have any route attached to it yet, the current code will
      let tb6_root and the node in the subtree share the same route.
      This could cause problem cause tb6_root has RTN_INFO flag marked and the
      tree repair and clean up code will not work properly.
      This commit makes sure tb6_root->leaf points back to null_entry instead
      of sharing route with other node.
      
      It fixes the following syzkaller reported issue:
      BUG: KASAN: use-after-free in ipv6_prefix_equal include/net/ipv6.h:540 [inline]
      BUG: KASAN: use-after-free in fib6_add_1+0x165f/0x1790 net/ipv6/ip6_fib.c:618
      Read of size 8 at addr ffff8801bc043498 by task syz-executor5/19819
      
      CPU: 1 PID: 19819 Comm: syz-executor5 Not tainted 4.15.0-rc7+ #186
      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/0x257 lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351 [inline]
       kasan_report+0x25b/0x340 mm/kasan/report.c:409
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
       ipv6_prefix_equal include/net/ipv6.h:540 [inline]
       fib6_add_1+0x165f/0x1790 net/ipv6/ip6_fib.c:618
       fib6_add+0x5fa/0x1540 net/ipv6/ip6_fib.c:1214
       __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1003
       ip6_route_add+0x141/0x190 net/ipv6/route.c:2790
       ipv6_route_ioctl+0x4db/0x6b0 net/ipv6/route.c:3299
       inet6_ioctl+0xef/0x1e0 net/ipv6/af_inet6.c:520
       sock_do_ioctl+0x65/0xb0 net/socket.c:958
       sock_ioctl+0x2c2/0x440 net/socket.c:1055
       vfs_ioctl fs/ioctl.c:46 [inline]
       do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
       SYSC_ioctl fs/ioctl.c:701 [inline]
       SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
       entry_SYSCALL_64_fastpath+0x23/0x9a
      RIP: 0033:0x452ac9
      RSP: 002b:00007fd42b321c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
      RDX: 0000000020fd7000 RSI: 000000000000890b RDI: 0000000000000013
      RBP: 000000000000049e R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f4f70
      R13: 00000000ffffffff R14: 00007fd42b3226d4 R15: 0000000000000000
      
      Fixes: 4512c43e
      
       ("ipv6: remove null_entry before adding default route")
      Signed-off-by: default avatarWei Wang <weiwan@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      591ff9ea
    • Alexey Kodanev's avatar
      ip6_gre: init dev->mtu and dev->hard_header_len correctly · 128bb975
      Alexey Kodanev authored
      Commit b05229f4 ("gre6: Cleanup GREv6 transmit path,
      call common GRE functions") moved dev->mtu initialization
      from ip6gre_tunnel_setup() to ip6gre_tunnel_init(), as a
      result, the previously set values, before ndo_init(), are
      reset in the following cases:
      
      * rtnl_create_link() can update dev->mtu from IFLA_MTU
        parameter.
      
      * ip6gre_tnl_link_config() is invoked before ndo_init() in
        netlink and ioctl setup, so ndo_init() can reset MTU
        adjustments with the lower device MTU as well, dev->mtu
        and dev->hard_header_len.
      
        Not applicable for ip6gretap because it has one more call
        to ip6gre_tnl_link_config(tunnel, 1) in ip6gre_tap_init().
      
      Fix the first case by updating dev->mtu with 'tb[IFLA_MTU]'
      parameter if a user sets it manually on a device creation,
      and fix the second one by moving ip6gre_tnl_link_config()
      call after register_netdevice().
      
      Fixes: b05229f4 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
      Fixes: db2ec95d
      
       ("ip6_gre: Fix MTU setting")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      128bb975
  2. 18 Jan, 2018 5 commits
    • Eric Dumazet's avatar
      flow_dissector: properly cap thoff field · d0c081b4
      Eric Dumazet authored
      syzbot reported yet another crash [1] that is caused by
      insufficient validation of DODGY packets.
      
      Two bugs are happening here to trigger the crash.
      
      1) Flow dissection leaves with incorrect thoff field.
      
      2) skb_probe_transport_header() sets transport header to this invalid
      thoff, even if pointing after skb valid data.
      
      3) qdisc_pkt_len_init() reads out-of-bound data because it
      trusts tcp_hdrlen(skb)
      
      Possible fixes :
      
      - Full flow dissector validation before injecting bad DODGY packets in
      the stack.
       This approach was attempted here : https://patchwork.ozlabs.org/patch/
      861874/
      
      - Have more robust functions in the core.
        This might be needed anyway for stable versions.
      
      This patch fixes the flow dissection issue.
      
      [1]
      CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49
      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/0x257 lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:355 [inline]
       kasan_report+0x23b/0x360 mm/kasan/report.c:413
       __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432
       __tcp_hdrlen include/linux/tcp.h:35 [inline]
       tcp_hdrlen include/linux/tcp.h:40 [inline]
       qdisc_pkt_len_init net/core/dev.c:3160 [inline]
       __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3554
       packet_snd net/packet/af_packet.c:2943 [inline]
       packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968
       sock_sendmsg_nosec net/socket.c:628 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:638
       sock_write_iter+0x31a/0x5d0 net/socket.c:907
       call_write_iter include/linux/fs.h:1776 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:482
       vfs_write+0x189/0x510 fs/read_write.c:544
       SYSC_write fs/read_write.c:589 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:581
       entry_SYSCALL_64_fastpath+0x1f/0x96
      
      Fixes: 34fad54c ("net: __skb_flow_dissect() must cap its return value")
      Fixes: a6e544b0
      
       ("flow_dissector: Jump to exit code in __skb_flow_dissect")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0c081b4
    • Johannes Berg's avatar
      cfg80211: fix station info handling bugs · 5762d7d3
      Johannes Berg authored
      Fix two places where the structure isn't initialized to zero,
      and thus can't be filled properly by the driver.
      
      Fixes: 4a4b8169 ("cfg80211: Accept multiple RSSI thresholds for CQM")
      Fixes: 9930380f
      
       ("cfg80211: implement IWRATE")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5762d7d3
    • Xin Long's avatar
      netlink: reset extack earlier in netlink_rcv_skb · cd443f1e
      Xin Long authored
      Move up the extack reset/initialization in netlink_rcv_skb, so that
      those 'goto ack' will not skip it. Otherwise, later on netlink_ack
      may use the uninitialized extack and cause kernel crash.
      
      Fixes: cbbdf843
      
       ("netlink: extack needs to be reset each time through loop")
      Reported-by: syzbot+03bee3680a37466775e7@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd443f1e
    • Marc Kleine-Budde's avatar
      can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once · d4689846
      Marc Kleine-Budde authored
      
      
      If an invalid CANFD frame is received, from a driver or from a tun
      interface, a Kernel warning is generated.
      
      This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
      kernel, bootet with panic_on_warn, does not panic. A printk seems to be
      more appropriate here.
      
      Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
      Suggested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      d4689846
    • Marc Kleine-Budde's avatar
      can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once · 8cb68751
      Marc Kleine-Budde authored
      
      
      If an invalid CAN frame is received, from a driver or from a tun
      interface, a Kernel warning is generated.
      
      This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
      kernel, bootet with panic_on_warn, does not panic. A printk seems to be
      more appropriate here.
      
      Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
      Suggested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      8cb68751
  3. 17 Jan, 2018 5 commits
    • Daniel Borkmann's avatar
      bpf: fix cls_bpf on filter replace · ad9294db
      Daniel Borkmann authored
      Running the following sequence is currently broken:
      
        # tc qdisc add dev foo clsact
        # tc filter replace dev foo ingress prio 1 handle 1 bpf da obj bar.o
        # tc filter replace dev foo ingress prio 1 handle 1 bpf da obj bar.o
        RTNETLINK answers: Invalid argument
      
      The normal expectation on kernel side is that the second command
      succeeds replacing the existing program. However, what happens is
      in cls_bpf_change(), we bail out with err in the second run in
      cls_bpf_offload(). The EINVAL comes directly in cls_bpf_offload()
      when comparing prog vs oldprog's gen_flags. In case of above
      replace the new prog's gen_flags are 0, but the old ones are 8,
      which means TCA_CLS_FLAGS_NOT_IN_HW is set (e.g. drivers not having
      cls_bpf offload).
      
      Fix 102740bd ("cls_bpf: fix offload assumptions after callback
      conversion") in the following way: gen_flags from user space passed
      down via netlink cannot include status flags like TCA_CLS_FLAGS_IN_HW
      or TCA_CLS_FLAGS_NOT_IN_HW as opposed to oldprog that we previously
      loaded. Therefore, it doesn't make any sense to include them in the
      gen_flags comparison with the new prog before we even attempt to
      offload. Thus, lets fix this before 4.15 goes out.
      
      Fixes: 102740bd
      
       ("cls_bpf: fix offload assumptions after callback conversion")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad9294db
    • Sabrina Dubroca's avatar
      tls: reset crypto_info when do_tls_setsockopt_tx fails · 6db959c8
      Sabrina Dubroca authored
      The current code copies directly from userspace to ctx->crypto_send, but
      doesn't always reinitialize it to 0 on failure. This causes any
      subsequent attempt to use this setsockopt to fail because of the
      TLS_CRYPTO_INFO_READY check, eventhough crypto_info is not actually
      ready.
      
      This should result in a correctly set up socket after the 3rd call, but
      currently it does not:
      
          size_t s = sizeof(struct tls12_crypto_info_aes_gcm_128);
          struct tls12_crypto_info_aes_gcm_128 crypto_good = {
              .info.version = TLS_1_2_VERSION,
              .info.cipher_type = TLS_CIPHER_AES_GCM_128,
          };
      
          struct tls12_crypto_info_aes_gcm_128 crypto_bad_type = crypto_good;
          crypto_bad_type.info.cipher_type = 42;
      
          setsockopt(sock, SOL_TLS, TLS_TX, &crypto_bad_type, s);
          setsockopt(sock, SOL_TLS, TLS_TX, &crypto_good, s - 1);
          setsockopt(sock, SOL_TLS, TLS_TX, &crypto_good, s);
      
      Fixes: 3c4d7559
      
       ("tls: kernel TLS support")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6db959c8
    • Sabrina Dubroca's avatar
      tls: return -EBUSY if crypto_info is already set · 877d17c7
      Sabrina Dubroca authored
      do_tls_setsockopt_tx returns 0 without doing anything when crypto_info
      is already set. Silent failure is confusing for users.
      
      Fixes: 3c4d7559
      
       ("tls: kernel TLS support")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      877d17c7
    • Sabrina Dubroca's avatar
      tls: fix sw_ctx leak · cf6d43ef
      Sabrina Dubroca authored
      During setsockopt(SOL_TCP, TLS_TX), if initialization of the software
      context fails in tls_set_sw_offload(), we leak sw_ctx. We also don't
      reassign ctx->priv_ctx to NULL, so we can't even do another attempt to
      set it up on the same socket, as it will fail with -EEXIST.
      
      Fixes: 3c4d7559
      
       ('tls: kernel TLS support')
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf6d43ef
    • Ilya Lesokhin's avatar
      net/tls: Only attach to sockets in ESTABLISHED state · d91c3e17
      Ilya Lesokhin authored
      Calling accept on a TCP socket with a TLS ulp attached results
      in two sockets that share the same ulp context.
      The ulp context is freed while a socket is destroyed, so
      after one of the sockets is released, the second second will
      trigger a use after free when it tries to access the ulp context
      attached to it.
      We restrict the TLS ulp to sockets in ESTABLISHED state
      to prevent the scenario above.
      
      Fixes: 3c4d7559
      
       ("tls: kernel TLS support")
      Reported-by: syzbot+904e7cd6c5c741609228@syzkaller.appspotmail.com
      Signed-off-by: default avatarIlya Lesokhin <ilyal@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d91c3e17
  4. 16 Jan, 2018 4 commits
    • Daniel Borkmann's avatar
      net, sched: fix panic when updating miniq {b,q}stats · 81d947e2
      Daniel Borkmann authored
      While working on fixing another bug, I ran into the following panic
      on arm64 by simply attaching clsact qdisc, adding a filter and running
      traffic on ingress to it:
      
        [...]
        [  178.188591] Unable to handle kernel read from unreadable memory at virtual address 810fb501f000
        [  178.197314] Mem abort info:
        [  178.200121]   ESR = 0x96000004
        [  178.203168]   Exception class = DABT (current EL), IL = 32 bits
        [  178.209095]   SET = 0, FnV = 0
        [  178.212157]   EA = 0, S1PTW = 0
        [  178.215288] Data abort info:
        [  178.218175]   ISV = 0, ISS = 0x00000004
        [  178.222019]   CM = 0, WnR = 0
        [  178.224997] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000023cb3f33
        [  178.231531] [0000810fb501f000] *pgd=0000000000000000
        [  178.236508] Internal error: Oops: 96000004 [#1] SMP
        [...]
        [  178.311855] CPU: 73 PID: 2497 Comm: ping Tainted: G        W        4.15.0-rc7+ #5
        [  178.319413] Hardware name: FOXCONN R2-1221R-A4/C2U4N_MB, BIOS G31FB18A 03/31/2017
        [  178.326887] pstate: 60400005 (nZCv daif +PAN -UAO)
        [  178.331685] pc : __netif_receive_skb_core+0x49c/0xac8
        [  178.336728] lr : __netif_receive_skb+0x28/0x78
        [  178.341161] sp : ffff00002344b750
        [  178.344465] x29: ffff00002344b750 x28: ffff810fbdfd0580
        [  178.349769] x27: 0000000000000000 x26: ffff000009378000
        [...]
        [  178.418715] x1 : 0000000000000054 x0 : 0000000000000000
        [  178.424020] Process ping (pid: 2497, stack limit = 0x000000009f0a3ff4)
        [  178.430537] Call trace:
        [  178.432976]  __netif_receive_skb_core+0x49c/0xac8
        [  178.437670]  __netif_receive_skb+0x28/0x78
        [  178.441757]  process_backlog+0x9c/0x160
        [  178.445584]  net_rx_action+0x2f8/0x3f0
        [...]
      
      Reason is that sch_ingress and sch_clsact are doing mini_qdisc_pair_init()
      which sets up miniq pointers to cpu_{b,q}stats from the underlying qdisc.
      Problem is that this cannot work since they are actually set up right after
      the qdisc ->init() callback in qdisc_create(), so first packet going into
      sch_handle_ingress() tries to call mini_qdisc_bstats_cpu_update() and we
      therefore panic.
      
      In order to fix this, allocation of {b,q}stats needs to happen before we
      call into ->init(). In net-next, there's already such option through commit
      d59f5ffa ("net: sched: a dflt qdisc may be used with per cpu stats").
      However, the bug needs to be fixed in net still for 4.15. Thus, include
      these bits to reduce any merge churn and reuse the static_flags field to
      set TCQ_F_CPUSTATS, and remove the allocation from qdisc_create() since
      there is no other user left. Prashant Bhole ran into the same issue but
      for net-next, thus adding him below as well as co-author. Same issue was
      also reported by Sandipan Das when using bcc.
      
      Fixes: 46209401 ("net: core: introduce mini_Qdisc and eliminate usage of tp->q for clsact fastpath")
      Reference: https://lists.iovisor.org/pipermail/iovisor-dev/2018-January/001190.html
      
      Reported-by: default avatarSandipan Das <sandipan@linux.vnet.ibm.com>
      Co-authored-by: default avatarPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Co-authored-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81d947e2
    • Xin Long's avatar
      sctp: do not allow the v4 socket to bind a v4mapped v6 address · c5006b8a
      Xin Long authored
      The check in sctp_sockaddr_af is not robust enough to forbid binding a
      v4mapped v6 addr on a v4 socket.
      
      The worse thing is that v4 socket's bind_verify would not convert this
      v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4
      socket bound a v6 addr.
      
      This patch is to fix it by doing the common sa.sa_family check first,
      then AF_INET check for v4mapped v6 addrs.
      
      Fixes: 7dab83de
      
       ("sctp: Support ipv6only AF_INET6 sockets.")
      Reported-by: syzbot+7b7b518b1228d2743963@syzkaller.appspotmail.com
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5006b8a
    • Xin Long's avatar
      sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf · a0ff6600
      Xin Long authored
      After commit cea0cc80 ("sctp: use the right sk after waking up from
      wait_buf sleep"), it may change to lock another sk if the asoc has been
      peeled off in sctp_wait_for_sndbuf.
      
      However, the asoc's new sk could be already closed elsewhere, as it's in
      the sendmsg context of the old sk that can't avoid the new sk's closing.
      If the sk's last one refcnt is held by this asoc, later on after putting
      this asoc, the new sk will be freed, while under it's own lock.
      
      This patch is to revert that commit, but fix the old issue by returning
      error under the old sk's lock.
      
      Fixes: cea0cc80
      
       ("sctp: use the right sk after waking up from wait_buf sleep")
      Reported-by: syzbot+ac6ea7baa4432811eb50@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0ff6600
    • Xin Long's avatar
      sctp: reinit stream if stream outcnt has been change by sinit in sendmsg · 625637bf
      Xin Long authored
      After introducing sctp_stream structure, sctp uses stream->outcnt as the
      out stream nums instead of c.sinit_num_ostreams.
      
      However when users use sinit in cmsg, it only updates c.sinit_num_ostreams
      in sctp_sendmsg. At that moment, stream->outcnt is still using previous
      value. If it's value is not updated, the sinit_num_ostreams of sinit could
      not really work.
      
      This patch is to fix it by updating stream->outcnt and reiniting stream
      if stream outcnt has been change by sinit in sendmsg.
      
      Fixes: a8386317
      
       ("sctp: prepare asoc stream for stream reconf")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      625637bf
  5. 15 Jan, 2018 15 commits
  6. 14 Jan, 2018 1 commit
  7. 10 Jan, 2018 8 commits