1. 03 10月, 2013 1 次提交
  2. 02 10月, 2013 2 次提交
  3. 01 10月, 2013 3 次提交
    • S
      ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put · 9260d3e1
      Salam Noureddine 提交于
      It is possible for the timer handlers to run after the call to
      ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the
      handler function in order to do proper cleanup when the refcnt
      reaches 0. Otherwise, the refcnt can reach zero without the
      inet6_dev being destroyed and we end up leaking a reference to
      the net_device and see messages like the following,
      
      unregister_netdevice: waiting for eth0 to become free. Usage count = 1
      
      Tested on linux-3.4.43.
      Signed-off-by: NSalam Noureddine <noureddine@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9260d3e1
    • H
      ipv6: gre: correct calculation of max_headroom · 3da812d8
      Hannes Frederic Sowa 提交于
      gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header,
      so initialize max_headroom to zero. Otherwise the
      
      	if (encap_limit >= 0) {
      		max_headroom += 8;
      		mtu -= 8;
      	}
      
      increments an uninitialized variable before max_headroom was reset.
      
      Found with coverity: 728539
      
      Cc: Dmitry Kozlov <xeb@mail.ru>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3da812d8
    • P
      ipv6: Fix preferred_lft not updating in some cases · c9d55d5b
      Paul Marks 提交于
      Consider the scenario where an IPv6 router is advertising a fixed
      preferred_lft of 1800 seconds, while the valid_lft begins at 3600
      seconds and counts down in realtime.
      
      A client should reset its preferred_lft to 1800 every time the RA is
      received, but a bug is causing Linux to ignore the update.
      
      The core problem is here:
        if (prefered_lft != ifp->prefered_lft) {
      
      Note that ifp->prefered_lft is an offset, so it doesn't decrease over
      time.  Thus, the comparison is always (1800 != 1800), which fails to
      trigger an update.
      
      The most direct solution would be to compute a "stored_prefered_lft",
      and use that value in the comparison.  But I think that trying to filter
      out unnecessary updates here is a premature optimization.  In order for
      the filter to apply, both of these would need to hold:
      
        - The advertised valid_lft and preferred_lft are both declining in
          real time.
        - No clock skew exists between the router & client.
      
      So in this patch, I've set "update_lft = 1" unconditionally, which
      allows the surrounding code to be greatly simplified.
      Signed-off-by: NPaul Marks <pmarks@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9d55d5b
  4. 30 9月, 2013 1 次提交
  5. 29 9月, 2013 1 次提交
  6. 24 9月, 2013 3 次提交
  7. 17 9月, 2013 1 次提交
  8. 13 9月, 2013 1 次提交
  9. 12 9月, 2013 4 次提交
  10. 06 9月, 2013 1 次提交
    • D
      ipv6:introduce function to find route for redirect · b55b76b2
      Duan Jiong 提交于
      RFC 4861 says that the IP source address of the Redirect is the
      same as the current first-hop router for the specified ICMP
      Destination Address, so the gateway should be taken into
      consideration when we find the route for redirect.
      
      There was once a check in commit
      a6279458 ("NDISC: Search over
      all possible rules on receipt of redirect.") and the check
      went away in commit b94f1c09
      ("ipv6: Use icmpv6_notify() to propagate redirect, instead of
      rt6_redirect()").
      
      The bug is only "exploitable" on layer-2 because the source
      address of the redirect is checked to be a valid link-local
      address but it makes spoofing a lot easier in the same L2
      domain nonetheless.
      
      Thanks very much for Hannes's help.
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b55b76b2
  11. 05 9月, 2013 10 次提交
  12. 04 9月, 2013 10 次提交
  13. 01 9月, 2013 2 次提交