1. 27 4月, 2017 2 次提交
    • J
      ipv6: check raw payload size correctly in ioctl · 105f5528
      Jamie Bainbridge 提交于
      In situations where an skb is paged, the transport header pointer and
      tail pointer can be the same because the skb contents are in frags.
      
      This results in ioctl(SIOCINQ/FIONREAD) incorrectly returning a
      length of 0 when the length to receive is actually greater than zero.
      
      skb->len is already correctly set in ip6_input_finish() with
      pskb_pull(), so use skb->len as it always returns the correct result
      for both linear and paged data.
      Signed-off-by: NJamie Bainbridge <jbainbri@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      105f5528
    • W
      ipv6: check skb->protocol before lookup for nexthop · 199ab00f
      WANG Cong 提交于
      Andrey reported a out-of-bound access in ip6_tnl_xmit(), this
      is because we use an ipv4 dst in ip6_tnl_xmit() and cast an IPv4
      neigh key as an IPv6 address:
      
              neigh = dst_neigh_lookup(skb_dst(skb),
                                       &ipv6_hdr(skb)->daddr);
              if (!neigh)
                      goto tx_err_link_failure;
      
              addr6 = (struct in6_addr *)&neigh->primary_key; // <=== HERE
              addr_type = ipv6_addr_type(addr6);
      
              if (addr_type == IPV6_ADDR_ANY)
                      addr6 = &ipv6_hdr(skb)->daddr;
      
              memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
      
      Also the network header of the skb at this point should be still IPv4
      for 4in6 tunnels, we shold not just use it as IPv6 header.
      
      This patch fixes it by checking if skb->protocol is ETH_P_IPV6: if it
      is, we are safe to do the nexthop lookup using skb_dst() and
      ipv6_hdr(skb)->daddr; if not (aka IPv4), we have no clue about which
      dest address we can pick here, we have to rely on callers to fill it
      from tunnel config, so just fall to ip6_route_output() to make the
      decision.
      
      Fixes: ea3dc960 ("ip6_tunnel: Add support for wildcard tunnel endpoints.")
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      199ab00f
  2. 26 4月, 2017 6 次提交
    • F
      netfilter: don't attach a nat extension by default · 9a08ecfe
      Florian Westphal 提交于
      nowadays the NAT extension only stores the interface index
      (used to purge connections that got masqueraded when interface goes down)
      and pptp nat information.
      
      Previous patches moved nf_ct_nat_ext_add to those places that need it.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      9a08ecfe
    • F
      netfilter: masquerade: attach nat extension if not present · ff459018
      Florian Westphal 提交于
      Currently the nat extension is always attached as soon as nat module is
      loaded.  However, most NAT uses do not need the nat extension anymore.
      
      Prepare to remove the add-nat-by-default by making those places that need
      it attach it if its not present yet.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ff459018
    • G
      netfilter: SYNPROXY: Return NF_STOLEN instead of NF_DROP during handshaking · 495dcb56
      Gao Feng 提交于
      Current SYNPROXY codes return NF_DROP during normal TCP handshaking,
      it is not friendly to caller. Because the nf_hook_slow would treat
      the NF_DROP as an error, and return -EPERM.
      As a result, it may cause the top caller think it meets one error.
      
      For example, the following codes are from cfv_rx_poll()
      	err = netif_receive_skb(skb);
      	if (unlikely(err)) {
      		++cfv->ndev->stats.rx_dropped;
      	} else {
      		++cfv->ndev->stats.rx_packets;
      		cfv->ndev->stats.rx_bytes += skb_len;
      	}
      When SYNPROXY returns NF_DROP, then netif_receive_skb returns -EPERM.
      As a result, the cfv driver would treat it as an error, and increase
      the rx_dropped counter.
      
      So use NF_STOLEN instead of NF_DROP now because there is no error
      happened indeed, and free the skb directly.
      Signed-off-by: NGao Feng <fgao@ikuai8.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      495dcb56
    • F
      netfilter: synproxy: only register hooks when needed · 1fefe147
      Florian Westphal 提交于
      Defer registration of the synproxy hooks until the first SYNPROXY rule is
      added.  Also means we only register hooks in namespaces that need it.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      1fefe147
    • D
      net: ipv6: regenerate host route if moved to gc list · 8048ced9
      David Ahern 提交于
      Taking down the loopback device wreaks havoc on IPv6 routing. By
      extension, taking down a VRF device wreaks havoc on its table.
      
      Dmitry and Andrey both reported heap out-of-bounds reports in the IPv6
      FIB code while running syzkaller fuzzer. The root cause is a dead dst
      that is on the garbage list gets reinserted into the IPv6 FIB. While on
      the gc (or perhaps when it gets added to the gc list) the dst->next is
      set to an IPv4 dst. A subsequent walk of the ipv6 tables causes the
      out-of-bounds access.
      
      Andrey's reproducer was the key to getting to the bottom of this.
      
      With IPv6, host routes for an address have the dst->dev set to the
      loopback device. When the 'lo' device is taken down, rt6_ifdown initiates
      a walk of the fib evicting routes with the 'lo' device which means all
      host routes are removed. That process moves the dst which is attached to
      an inet6_ifaddr to the gc list and marks it as dead.
      
      The recent change to keep global IPv6 addresses added a new function,
      fixup_permanent_addr, that is called on admin up. That function restarts
      dad for an inet6_ifaddr and when it completes the host route attached
      to it is inserted into the fib. Since the route was marked dead and
      moved to the gc list, re-inserting the route causes the reported
      out-of-bounds accesses. If the device with the address is taken down
      or the address is removed, the WARN_ON in fib6_del is triggered.
      
      All of those faults are fixed by regenerating the host route if the
      existing one has been moved to the gc list, something that can be
      determined by checking if the rt6i_ref counter is 0.
      
      Fixes: f1705ec1 ("net: ipv6: Make address flushing on ifdown optional")
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8048ced9
    • S
      ipv6: fix source routing · ec9c4215
      Sabrina Dubroca 提交于
      Commit a149e7c7 ("ipv6: sr: add support for SRH injection through
      setsockopt") introduced handling of IPV6_SRCRT_TYPE_4, but at the same
      time restricted it to only IPV6_SRCRT_TYPE_0 and
      IPV6_SRCRT_TYPE_4. Previously, ipv6_push_exthdr() and fl6_update_dst()
      would also handle other values (ie STRICT and TYPE_2).
      
      Restore previous source routing behavior, by handling IPV6_SRCRT_STRICT
      and IPV6_SRCRT_TYPE_2 the same way as IPV6_SRCRT_TYPE_0 in
      ipv6_push_exthdr() and fl6_update_dst().
      
      Fixes: a149e7c7 ("ipv6: sr: add support for SRH injection through setsockopt")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec9c4215
  3. 25 4月, 2017 2 次提交
  4. 24 4月, 2017 1 次提交
  5. 22 4月, 2017 5 次提交
    • N
      ip6mr: fix notification device destruction · 723b929c
      Nikolay Aleksandrov 提交于
      Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
      because we call unregister_netdevice_many for a device that is already
      being destroyed. In IPv4's ipmr that has been resolved by two commits
      long time ago by introducing the "notify" parameter to the delete
      function and avoiding the unregister when called from a notifier, so
      let's do the same for ip6mr.
      
      The trace from Andrey:
      ------------[ cut here ]------------
      kernel BUG at net/core/dev.c:6813!
      invalid opcode: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
      Workqueue: netns cleanup_net
      task: ffff880069208000 task.stack: ffff8800692d8000
      RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
      RSP: 0018:ffff8800692de7f0 EFLAGS: 00010297
      RAX: ffff880069208000 RBX: 0000000000000002 RCX: 0000000000000001
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88006af90569
      RBP: ffff8800692de9f0 R08: ffff8800692dec60 R09: 0000000000000000
      R10: 0000000000000006 R11: 0000000000000000 R12: ffff88006af90070
      R13: ffff8800692debf0 R14: dffffc0000000000 R15: ffff88006af90000
      FS:  0000000000000000(0000) GS:ffff88006cb00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fe7e897d870 CR3: 00000000657e7000 CR4: 00000000000006e0
      Call Trace:
       unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
       unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
       ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
       notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
       call_netdevice_notifiers net/core/dev.c:1663
       rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
       unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
       unregister_netdevice_many net/core/dev.c:7880
       default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
       ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
       cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
       process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
       worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
       kthread+0x35e/0x430 kernel/kthread.c:231
       ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
      Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
      47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
      0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
      RIP: rollback_registered_many+0x348/0xeb0 RSP: ffff8800692de7f0
      ---[ end trace e0b29c57e9b3292c ]---
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      723b929c
    • D
      net: ipv6: RTF_PCPU should not be settable from userspace · 557c44be
      David Ahern 提交于
      Andrey reported a fault in the IPv6 route code:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 1 PID: 4035 Comm: a.out Not tainted 4.11.0-rc7+ #250
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      task: ffff880069809600 task.stack: ffff880062dc8000
      RIP: 0010:ip6_rt_cache_alloc+0xa6/0x560 net/ipv6/route.c:975
      RSP: 0018:ffff880062dced30 EFLAGS: 00010206
      RAX: dffffc0000000000 RBX: ffff8800670561c0 RCX: 0000000000000006
      RDX: 0000000000000003 RSI: ffff880062dcfb28 RDI: 0000000000000018
      RBP: ffff880062dced68 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff880062dcfb28 R14: dffffc0000000000 R15: 0000000000000000
      FS:  00007feebe37e7c0(0000) GS:ffff88006cb00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000205a0fe4 CR3: 000000006b5c9000 CR4: 00000000000006e0
      Call Trace:
       ip6_pol_route+0x1512/0x1f20 net/ipv6/route.c:1128
       ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212
      ...
      
      Andrey's syzkaller program passes rtmsg.rtmsg_flags with the RTF_PCPU bit
      set. Flags passed to the kernel are blindly copied to the allocated
      rt6_info by ip6_route_info_create making a newly inserted route appear
      as though it is a per-cpu route. ip6_rt_cache_alloc sees the flag set
      and expects rt->dst.from to be set - which it is not since it is not
      really a per-cpu copy. The subsequent call to __ip6_dst_alloc then
      generates the fault.
      
      Fix by checking for the flag and failing with EINVAL.
      
      Fixes: d52d3997 ("ipv6: Create percpu rt6_info")
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      557c44be
    • C
      ip_tunnel: Allow policy-based routing through tunnels · 9830ad4c
      Craig Gallek 提交于
      This feature allows the administrator to set an fwmark for
      packets traversing a tunnel.  This allows the use of independent
      routing tables for tunneled packets without the use of iptables.
      
      There is no concept of per-packet routing decisions through IPv4
      tunnels, so this implementation does not need to work with
      per-packet route lookups as the v6 implementation may
      (with IP6_TNL_F_USE_ORIG_FWMARK).
      
      Further, since the v4 tunnel ioctls share datastructures
      (which can not be trivially modified) with the kernel's internal
      tunnel configuration structures, the mark attribute must be stored
      in the tunnel structure itself and passed as a parameter when
      creating or changing tunnel attributes.
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9830ad4c
    • C
      ip6_tunnel: Allow policy-based routing through tunnels · 0a473b82
      Craig Gallek 提交于
      This feature allows the administrator to set an fwmark for
      packets traversing a tunnel.  This allows the use of independent
      routing tables for tunneled packets without the use of iptables.
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a473b82
    • D
      ipv6: sr: fix double free of skb after handling invalid SRH · 95b9b88d
      David Lebrun 提交于
      The icmpv6_param_prob() function already does a kfree_skb(),
      this patch removes the duplicate one.
      
      Fixes: 1ababeba ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid Lebrun <david.lebrun@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      95b9b88d
  6. 21 4月, 2017 2 次提交
  7. 19 4月, 2017 2 次提交
  8. 18 4月, 2017 5 次提交
    • D
      net: rtnetlink: plumb extended ack to doit function · c21ef3e3
      David Ahern 提交于
      Add netlink_ext_ack arg to rtnl_doit_func. Pass extack arg to nlmsg_parse
      for doit functions that call it directly.
      
      This is the first step to using extended error reporting in rtnetlink.
      >From here individual subsystems can be updated to set netlink_ext_ack as
      needed.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c21ef3e3
    • D
      ipv6: sr: fix BUG due to headroom too small after SRH push · af3b5158
      David Lebrun 提交于
      When a locally generated packet receives an SRH with two or more segments,
      the remaining headroom is too small to push an ethernet header. This patch
      ensures that the headroom is large enough after SRH push.
      
      The BUG generated the following trace.
      
      [  192.950285] skbuff: skb_under_panic: text:ffffffff81809675 len:198 put:14 head:ffff88006f306400 data:ffff88006f3063fa tail:0xc0 end:0x2c0 dev:A-1
      [  192.952456] ------------[ cut here ]------------
      [  192.953218] kernel BUG at net/core/skbuff.c:105!
      [  192.953411] invalid opcode: 0000 [#1] PREEMPT SMP
      [  192.953411] Modules linked in:
      [  192.953411] CPU: 5 PID: 3433 Comm: ping6 Not tainted 4.11.0-rc3+ #237
      [  192.953411] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
      [  192.953411] task: ffff88007c2d42c0 task.stack: ffffc90000ef4000
      [  192.953411] RIP: 0010:skb_panic+0x61/0x70
      [  192.953411] RSP: 0018:ffffc90000ef7900 EFLAGS: 00010286
      [  192.953411] RAX: 0000000000000085 RBX: 00000000000086dd RCX: 0000000000000201
      [  192.953411] RDX: 0000000080000201 RSI: ffffffff81d104c5 RDI: 00000000ffffffff
      [  192.953411] RBP: ffffc90000ef7920 R08: 0000000000000001 R09: 0000000000000000
      [  192.953411] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      [  192.953411] R13: ffff88007c5a4000 R14: ffff88007b363d80 R15: 00000000000000b8
      [  192.953411] FS:  00007f94b558b700(0000) GS:ffff88007fd40000(0000) knlGS:0000000000000000
      [  192.953411] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  192.953411] CR2: 00007fff5ecd5080 CR3: 0000000074141000 CR4: 00000000001406e0
      [  192.953411] Call Trace:
      [  192.953411]  skb_push+0x3b/0x40
      [  192.953411]  eth_header+0x25/0xc0
      [  192.953411]  neigh_resolve_output+0x168/0x230
      [  192.953411]  ? ip6_finish_output2+0x242/0x8f0
      [  192.953411]  ip6_finish_output2+0x242/0x8f0
      [  192.953411]  ? ip6_finish_output2+0x76/0x8f0
      [  192.953411]  ip6_finish_output+0xa8/0x1d0
      [  192.953411]  ip6_output+0x64/0x2d0
      [  192.953411]  ? ip6_output+0x73/0x2d0
      [  192.953411]  ? ip6_dst_check+0xb5/0xc0
      [  192.953411]  ? dst_cache_per_cpu_get.isra.2+0x40/0x80
      [  192.953411]  seg6_output+0xb0/0x220
      [  192.953411]  lwtunnel_output+0xcf/0x210
      [  192.953411]  ? lwtunnel_output+0x59/0x210
      [  192.953411]  ip6_local_out+0x38/0x70
      [  192.953411]  ip6_send_skb+0x2a/0xb0
      [  192.953411]  ip6_push_pending_frames+0x48/0x50
      [  192.953411]  rawv6_sendmsg+0xa39/0xf10
      [  192.953411]  ? __lock_acquire+0x489/0x890
      [  192.953411]  ? __mutex_lock+0x1fc/0x970
      [  192.953411]  ? __lock_acquire+0x489/0x890
      [  192.953411]  ? __mutex_lock+0x1fc/0x970
      [  192.953411]  ? tty_ioctl+0x283/0xec0
      [  192.953411]  inet_sendmsg+0x45/0x1d0
      [  192.953411]  ? _copy_from_user+0x54/0x80
      [  192.953411]  sock_sendmsg+0x33/0x40
      [  192.953411]  SYSC_sendto+0xef/0x170
      [  192.953411]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
      [  192.953411]  ? trace_hardirqs_on_caller+0x12b/0x1b0
      [  192.953411]  ? trace_hardirqs_on_thunk+0x1a/0x1c
      [  192.953411]  SyS_sendto+0x9/0x10
      [  192.953411]  entry_SYSCALL_64_fastpath+0x1f/0xc2
      [  192.953411] RIP: 0033:0x7f94b453db33
      [  192.953411] RSP: 002b:00007fff5ecd0578 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [  192.953411] RAX: ffffffffffffffda RBX: 00007fff5ecd16e0 RCX: 00007f94b453db33
      [  192.953411] RDX: 0000000000000040 RSI: 000055a78352e9c0 RDI: 0000000000000003
      [  192.953411] RBP: 00007fff5ecd1690 R08: 000055a78352c940 R09: 000000000000001c
      [  192.953411] R10: 0000000000000000 R11: 0000000000000246 R12: 000055a783321e10
      [  192.953411] R13: 000055a7839890c0 R14: 0000000000000004 R15: 0000000000000000
      [  192.953411] Code: 00 00 48 89 44 24 10 8b 87 c4 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 90 58 d2 81 48 89 04 24 31 c0 e8 4f 70 9a ff <0f> 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 97 d8 00 00
      [  192.953411] RIP: skb_panic+0x61/0x70 RSP: ffffc90000ef7900
      [  193.000186] ---[ end trace bd0b89fabdf2f92c ]---
      [  193.000951] Kernel panic - not syncing: Fatal exception in interrupt
      [  193.001137] Kernel Offset: disabled
      [  193.001169] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      Fixes: 19d5a26f ("ipv6: sr: expand skb head only if necessary")
      Signed-off-by: NDavid Lebrun <david.lebrun@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af3b5158
    • F
      ipv6: drop non loopback packets claiming to originate from ::1 · 0aa8c13e
      Florian Westphal 提交于
      We lack a saddr check for ::1. This causes security issues e.g. with acls
      permitting connections from ::1 because of assumption that these originate
      from local machine.
      
      Assuming a source address of ::1 is local seems reasonable.
      RFC4291 doesn't allow such a source address either, so drop such packets.
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0aa8c13e
    • W
      net-timestamp: avoid use-after-free in ip_recv_error · 1862d620
      Willem de Bruijn 提交于
      Syzkaller reported a use-after-free in ip_recv_error at line
      
          info->ipi_ifindex = skb->dev->ifindex;
      
      This function is called on dequeue from the error queue, at which
      point the device pointer may no longer be valid.
      
      Save ifindex on enqueue in __skb_complete_tx_timestamp, when the
      pointer is valid or NULL. Store it in temporary storage skb->cb.
      
      It is safe to reference skb->dev here, as called from device drivers
      or dev_queue_xmit. The exception is when called from tcp_ack_tstamp;
      in that case it is NULL and ifindex is set to 0 (invalid).
      
      Do not return a pktinfo cmsg if ifindex is 0. This maintains the
      current behavior of not returning a cmsg if skb->dev was NULL.
      
      On dequeue, the ipv4 path will cast from sock_exterr_skb to
      in_pktinfo. Both have ifindex as their first element, so no explicit
      conversion is needed. This is by design, introduced in commit
      0b922b7a ("net: original ingress device index in PKTINFO"). For
      ipv6 ip6_datagram_support_cmsg converts to in6_pktinfo.
      
      Fixes: 829ae9d6 ("net-timestamp: allow reading recv cmsg on errqueue with origin tstamp")
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1862d620
    • D
      net: ipv6: send unsolicited NA on admin up · 4a6e3c5d
      David Ahern 提交于
      ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is
      set to 1, gratuitous arp requests are sent when the device is brought up.
      The same is expected when ndisc_notify is set to 1 (per ndisc_notify in
      Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP
      event; add it.
      
      Fixes: 5cb04436 ("ipv6: add knob to send unsolicited ND on link-layer address change")
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a6e3c5d
  9. 15 4月, 2017 2 次提交
    • F
      netfilter: remove nf_ct_is_untracked · ab8bc7ed
      Florian Westphal 提交于
      This function is now obsolete and always returns false.
      This change has no effect on generated code.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ab8bc7ed
    • F
      netfilter: kill the fake untracked conntrack objects · cc41c84b
      Florian Westphal 提交于
      resurrect an old patch from Pablo Neira to remove the untracked objects.
      
      Currently, there are four possible states of an skb wrt. conntrack.
      
      1. No conntrack attached, ct is NULL.
      2. Normal (kmem cache allocated) ct attached.
      3. a template (kmalloc'd), not in any hash tables at any point in time
      4. the 'untracked' conntrack, a percpu nf_conn object, tagged via
         IPS_UNTRACKED_BIT in ct->status.
      
      Untracked is supposed to be identical to case 1.  It exists only
      so users can check
      
      -m conntrack --ctstate UNTRACKED vs.
      -m conntrack --ctstate INVALID
      
      e.g. attempts to set connmark on INVALID or UNTRACKED conntracks is
      supposed to be a no-op.
      
      Thus currently we need to check
       ct == NULL || nf_ct_is_untracked(ct)
      
      in a lot of places in order to avoid altering untracked objects.
      
      The other consequence of the percpu untracked object is that all
      -j NOTRACK (and, later, kfree_skb of such skbs) result in an atomic op
      (inc/dec the untracked conntracks refcount).
      
      This adds a new kernel-private ctinfo state, IP_CT_UNTRACKED, to
      make the distinction instead.
      
      The (few) places that care about packet invalid (ct is NULL) vs.
      packet untracked now need to test ct == NULL vs. ctinfo == IP_CT_UNTRACKED,
      but all other places can omit the nf_ct_is_untracked() check.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      cc41c84b
  10. 14 4月, 2017 9 次提交
  11. 13 4月, 2017 3 次提交
  12. 09 4月, 2017 1 次提交