1. 06 10月, 2019 1 次提交
  2. 08 7月, 2019 1 次提交
    • X
      tipc: use rcu dereference functions properly · 30a4616c
      Xin Long 提交于
      For these places are protected by rcu_read_lock, we change from
      rcu_dereference_rtnl to rcu_dereference, as there is no need to
      check if rtnl lock is held.
      
      For these places are protected by rtnl_lock, we change from
      rcu_dereference_rtnl to rtnl_dereference/rcu_dereference_protected,
      as no extra memory barriers are needed under rtnl_lock() which also
      protects tn->bearer_list[] and dev->tipc_ptr/b->media_ptr updating.
      
      rcu_dereference_rtnl will be only used in the places where it could
      be under rcu_read_lock or rtnl_lock.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30a4616c
  3. 03 7月, 2019 1 次提交
  4. 28 6月, 2019 1 次提交
  5. 19 6月, 2019 1 次提交
    • X
      tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb · c3bcde02
      Xin Long 提交于
      udp_tunnel(6)_xmit_skb() called by tipc_udp_xmit() expects a tunnel device
      to count packets on dev->tstats, a perpcu variable. However, TIPC is using
      udp tunnel with no tunnel device, and pass the lower dev, like veth device
      that only initializes dev->lstats(a perpcu variable) when creating it.
      
      Later iptunnel_xmit_stats() called by ip(6)tunnel_xmit() thinks the dev as
      a tunnel device, and uses dev->tstats instead of dev->lstats. tstats' each
      pointer points to a bigger struct than lstats, so when tstats->tx_bytes is
      increased, other percpu variable's members could be overwritten.
      
      syzbot has reported quite a few crashes due to fib_nh_common percpu member
      'nhc_pcpu_rth_output' overwritten, call traces are like:
      
        BUG: KASAN: slab-out-of-bounds in rt_cache_valid+0x158/0x190
        net/ipv4/route.c:1556
          rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556
          __mkroute_output net/ipv4/route.c:2332 [inline]
          ip_route_output_key_hash_rcu+0x819/0x2d50 net/ipv4/route.c:2564
          ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393
          __ip_route_output_key include/net/route.h:125 [inline]
          ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651
          ip_route_output_key include/net/route.h:135 [inline]
        ...
      
      or:
      
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        RIP: 0010:dst_dev_put+0x24/0x290 net/core/dst.c:168
          <IRQ>
          rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:200 [inline]
          free_fib_info_rcu+0x2e1/0x490 net/ipv4/fib_semantics.c:217
          __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
          rcu_do_batch kernel/rcu/tree.c:2437 [inline]
          invoke_rcu_callbacks kernel/rcu/tree.c:2716 [inline]
          rcu_process_callbacks+0x100a/0x1ac0 kernel/rcu/tree.c:2697
        ...
      
      The issue exists since tunnel stats update is moved to iptunnel_xmit by
      Commit 039f5062 ("ip_tunnel: Move stats update to iptunnel_xmit()"),
      and here to fix it by passing a NULL tunnel dev to udp_tunnel(6)_xmit_skb
      so that the packets counting won't happen on dev->tstats.
      
      Reported-by: syzbot+9d4c12bfd45a58738d0a@syzkaller.appspotmail.com
      Reported-by: syzbot+a9e23ea2aa21044c2798@syzkaller.appspotmail.com
      Reported-by: syzbot+c4c4b2bb358bb936ad7e@syzkaller.appspotmail.com
      Reported-by: syzbot+0290d2290a607e035ba1@syzkaller.appspotmail.com
      Reported-by: syzbot+a43d8d4e7e8a7a9e149e@syzkaller.appspotmail.com
      Reported-by: syzbot+a47c5f4c6c00fc1ed16e@syzkaller.appspotmail.com
      Fixes: 039f5062 ("ip_tunnel: Move stats update to iptunnel_xmit()")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3bcde02
  6. 28 4月, 2019 2 次提交
    • J
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg 提交于
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb08174
    • 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
  7. 27 4月, 2019 1 次提交
  8. 25 4月, 2019 1 次提交
  9. 30 3月, 2019 1 次提交
  10. 15 12月, 2018 2 次提交
  11. 16 10月, 2018 1 次提交
  12. 20 4月, 2018 1 次提交
  13. 27 3月, 2018 1 次提交
  14. 24 3月, 2018 1 次提交
  15. 02 12月, 2017 1 次提交
    • T
      tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv() · c7799c06
      Tommi Rantala 提交于
      Remove the second tipc_rcv() call in tipc_udp_recv(). We have just
      checked that the bearer is not up, and calling tipc_rcv() with a bearer
      that is not up leads to a TIPC div-by-zero crash in
      tipc_node_calculate_timer(). The crash is rare in practice, but can
      happen like this:
      
        We're enabling a bearer, but it's not yet up and fully initialized.
        At the same time we receive a discovery packet, and in tipc_udp_recv()
        we end up calling tipc_rcv() with the not-yet-initialized bearer,
        causing later the div-by-zero crash in tipc_node_calculate_timer().
      
      Jon Maloy explains the impact of removing the second tipc_rcv() call:
        "link setup in the worst case will be delayed until the next arriving
         discovery messages, 1 sec later, and this is an acceptable delay."
      
      As the tipc_rcv() call is removed, just leave the function via the
      rcu_out label, so that we will kfree_skb().
      
      [   12.590450] Own node address <1.1.1>, network identity 1
      [   12.668088] divide error: 0000 [#1] SMP
      [   12.676952] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.2-dirty #1
      [   12.679225] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
      [   12.682095] task: ffff8c2a761edb80 task.stack: ffffa41cc0cac000
      [   12.684087] RIP: 0010:tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc]
      [   12.686486] RSP: 0018:ffff8c2a7fc838a0 EFLAGS: 00010246
      [   12.688451] RAX: 0000000000000000 RBX: ffff8c2a5b382600 RCX: 0000000000000000
      [   12.691197] RDX: 0000000000000000 RSI: ffff8c2a5b382600 RDI: ffff8c2a5b382600
      [   12.693945] RBP: ffff8c2a7fc838b0 R08: 0000000000000001 R09: 0000000000000001
      [   12.696632] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c2a5d8949d8
      [   12.699491] R13: ffffffff95ede400 R14: 0000000000000000 R15: ffff8c2a5d894800
      [   12.702338] FS:  0000000000000000(0000) GS:ffff8c2a7fc80000(0000) knlGS:0000000000000000
      [   12.705099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   12.706776] CR2: 0000000001bb9440 CR3: 00000000bd009001 CR4: 00000000003606e0
      [   12.708847] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   12.711016] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   12.712627] Call Trace:
      [   12.713390]  <IRQ>
      [   12.714011]  tipc_node_check_dest+0x2e8/0x350 [tipc]
      [   12.715286]  tipc_disc_rcv+0x14d/0x1d0 [tipc]
      [   12.716370]  tipc_rcv+0x8b0/0xd40 [tipc]
      [   12.717396]  ? minmax_running_min+0x2f/0x60
      [   12.718248]  ? dst_alloc+0x4c/0xa0
      [   12.718964]  ? tcp_ack+0xaf1/0x10b0
      [   12.719658]  ? tipc_udp_is_known_peer+0xa0/0xa0 [tipc]
      [   12.720634]  tipc_udp_recv+0x71/0x1d0 [tipc]
      [   12.721459]  ? dst_alloc+0x4c/0xa0
      [   12.722130]  udp_queue_rcv_skb+0x264/0x490
      [   12.722924]  __udp4_lib_rcv+0x21e/0x990
      [   12.723670]  ? ip_route_input_rcu+0x2dd/0xbf0
      [   12.724442]  ? tcp_v4_rcv+0x958/0xa40
      [   12.725039]  udp_rcv+0x1a/0x20
      [   12.725587]  ip_local_deliver_finish+0x97/0x1d0
      [   12.726323]  ip_local_deliver+0xaf/0xc0
      [   12.726959]  ? ip_route_input_noref+0x19/0x20
      [   12.727689]  ip_rcv_finish+0xdd/0x3b0
      [   12.728307]  ip_rcv+0x2ac/0x360
      [   12.728839]  __netif_receive_skb_core+0x6fb/0xa90
      [   12.729580]  ? udp4_gro_receive+0x1a7/0x2c0
      [   12.730274]  __netif_receive_skb+0x1d/0x60
      [   12.730953]  ? __netif_receive_skb+0x1d/0x60
      [   12.731637]  netif_receive_skb_internal+0x37/0xd0
      [   12.732371]  napi_gro_receive+0xc7/0xf0
      [   12.732920]  receive_buf+0x3c3/0xd40
      [   12.733441]  virtnet_poll+0xb1/0x250
      [   12.733944]  net_rx_action+0x23e/0x370
      [   12.734476]  __do_softirq+0xc5/0x2f8
      [   12.734922]  irq_exit+0xfa/0x100
      [   12.735315]  do_IRQ+0x4f/0xd0
      [   12.735680]  common_interrupt+0xa2/0xa2
      [   12.736126]  </IRQ>
      [   12.736416] RIP: 0010:native_safe_halt+0x6/0x10
      [   12.736925] RSP: 0018:ffffa41cc0cafe90 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff4d
      [   12.737756] RAX: 0000000000000000 RBX: ffff8c2a761edb80 RCX: 0000000000000000
      [   12.738504] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      [   12.739258] RBP: ffffa41cc0cafe90 R08: 0000014b5b9795e5 R09: ffffa41cc12c7e88
      [   12.740118] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
      [   12.740964] R13: ffff8c2a761edb80 R14: 0000000000000000 R15: 0000000000000000
      [   12.741831]  default_idle+0x2a/0x100
      [   12.742323]  arch_cpu_idle+0xf/0x20
      [   12.742796]  default_idle_call+0x28/0x40
      [   12.743312]  do_idle+0x179/0x1f0
      [   12.743761]  cpu_startup_entry+0x1d/0x20
      [   12.744291]  start_secondary+0x112/0x120
      [   12.744816]  secondary_startup_64+0xa5/0xa5
      [   12.745367] Code: b9 f4 01 00 00 48 89 c2 48 c1 ea 02 48 3d d3 07 00
      00 48 0f 47 d1 49 8b 0c 24 48 39 d1 76 07 49 89 14 24 48 89 d1 31 d2 48
      89 df <48> f7 f1 89 c6 e8 81 6e ff ff 5b 41 5c 5d c3 66 90 66 2e 0f 1f
      [   12.747527] RIP: tipc_node_calculate_timer.isra.12+0x45/0x60 [tipc] RSP: ffff8c2a7fc838a0
      [   12.748555] ---[ end trace 1399ab83390650fd ]---
      [   12.749296] Kernel panic - not syncing: Fatal exception in interrupt
      [   12.750123] Kernel Offset: 0x13200000 from 0xffffffff82000000
      (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [   12.751215] Rebooting in 60 seconds..
      
      Fixes: c9b64d49 ("tipc: add replicast peer discovery")
      Signed-off-by: NTommi Rantala <tommi.t.rantala@nokia.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7799c06
  16. 14 4月, 2017 1 次提交
  17. 21 1月, 2017 1 次提交
  18. 03 12月, 2016 1 次提交
    • M
      tipc: check minimum bearer MTU · 3de81b75
      Michal Kubeček 提交于
      Qian Zhang (张谦) reported a potential socket buffer overflow in
      tipc_msg_build() which is also known as CVE-2016-8632: due to
      insufficient checks, a buffer overflow can occur if MTU is too short for
      even tipc headers. As anyone can set device MTU in a user/net namespace,
      this issue can be abused by a regular user.
      
      As agreed in the discussion on Ben Hutchings' original patch, we should
      check the MTU at the moment a bearer is attached rather than for each
      processed packet. We also need to repeat the check when bearer MTU is
      adjusted to new device MTU. UDP case also needs a check to avoid
      overflow when calculating bearer MTU.
      
      Fixes: b97bf3fd ("[TIPC] Initial merge")
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Reported-by: NQian Zhang (张谦) <zhangqian-c@360.cn>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3de81b75
  19. 14 10月, 2016 1 次提交
  20. 13 9月, 2016 1 次提交
  21. 27 8月, 2016 7 次提交
  22. 26 8月, 2016 1 次提交
  23. 19 8月, 2016 1 次提交
    • J
      tipc: make bearer packet filtering generic · 0d051bf9
      Jon Paul Maloy 提交于
      In commit 5b7066c3 ("tipc: stricter filtering of packets in bearer
      layer") we introduced a method of filtering out messages while a bearer
      is being reset, to avoid that links may be re-created and come back in
      working state while we are still in the process of shutting them down.
      
      This solution works well, but is limited to only work with L2 media, which
      is insufficient with the increasing use of UDP as carrier media.
      
      We now replace this solution with a more generic one, by introducing a
      new flag "up" in the generic struct tipc_bearer. This field will be set
      and reset at the same locations as with the previous solution, while
      the packet filtering is moved to the generic code for the sending side.
      On the receiving side, the filtering is still done in media specific
      code, but now including the UDP bearer.
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d051bf9
  24. 29 6月, 2016 1 次提交
  25. 15 3月, 2016 1 次提交
  26. 12 3月, 2016 1 次提交
  27. 08 3月, 2016 1 次提交
  28. 07 3月, 2016 3 次提交
  29. 26 12月, 2015 1 次提交
  30. 25 11月, 2015 1 次提交
    • Y
      tipc: fix error handling of expanding buffer headroom · 7098356b
      Ying Xue 提交于
      Coverity says:
      
      *** CID 1338065:  Error handling issues  (CHECKED_RETURN)
      /net/tipc/udp_media.c: 162 in tipc_udp_send_msg()
      156     	struct udp_media_addr *dst = (struct udp_media_addr *)&dest->value;
      157     	struct udp_media_addr *src = (struct udp_media_addr *)&b->addr.value;
      158     	struct sk_buff *clone;
      159     	struct rtable *rt;
      160
      161     	if (skb_headroom(skb) < UDP_MIN_HEADROOM)
      >>>     CID 1338065:  Error handling issues  (CHECKED_RETURN)
      >>>     Calling "pskb_expand_head" without checking return value (as is done elsewhere 51 out of 56 times).
      162     		pskb_expand_head(skb, UDP_MIN_HEADROOM, 0, GFP_ATOMIC);
      163
      164     	clone = skb_clone(skb, GFP_ATOMIC);
      165     	skb_set_inner_protocol(clone, htons(ETH_P_TIPC));
      166     	ub = rcu_dereference_rtnl(b->media_ptr);
      167     	if (!ub) {
      
      When expanding buffer headroom over udp tunnel with pskb_expand_head(),
      it's unfortunate that we don't check its return value. As a result, if
      the function returns an error code due to the lack of memory, it may
      cause unpredictable consequence as we unconditionally consider that
      it's always successful.
      
      Fixes: e5356794 ("tipc: conditionally expand buffer headroom over udp tunnel")
      Reported-by: <scan-admin@coverity.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7098356b