1. 25 8月, 2014 1 次提交
  2. 14 3月, 2014 1 次提交
  3. 07 12月, 2013 1 次提交
  4. 16 9月, 2013 1 次提交
  5. 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
  6. 12 7月, 2012 1 次提交
  7. 16 6月, 2012 1 次提交
    • D
      ipv6: Handle PMTU in ICMP error handlers. · 81aded24
      David S. Miller 提交于
      One tricky issue on the ipv6 side vs. ipv4 is that the ICMP callouts
      to handle the error pass the 32-bit info cookie in network byte order
      whereas ipv4 passes it around in host byte order.
      
      Like the ipv4 side, we have two helper functions.  One for when we
      have a socket context and one for when we do not.
      
      ip6ip6 tunnels are not handled here, because they handle PMTU events
      by essentially relaying another ICMP packet-too-big message back to
      the original sender.
      
      This patch allows us to get rid of rt6_do_pmtu_disc().  It handles all
      kinds of situations that simply cannot happen when we do the PMTU
      update directly using a fully resolved route.
      
      In fact, the "plen == 128" check in ip6_rt_update_pmtu() can very
      likely be removed or changed into a BUG_ON() check.  We should never
      have a prefixed ipv6 route when we get there.
      
      Another piece of strange history here is that TCP and DCCP, unlike in
      ipv4, never invoke the update_pmtu() method from their ICMP error
      handlers.  This is incredibly astonishing since this is the context
      where we have the most accurate context in which to make a PMTU
      update, namely we have a fully connected socket and associated cached
      socket route.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81aded24
  8. 16 5月, 2012 2 次提交
  9. 23 4月, 2011 1 次提交
  10. 23 2月, 2010 1 次提交
  11. 17 2月, 2010 1 次提交
  12. 28 1月, 2010 2 次提交
  13. 15 9月, 2009 1 次提交
  14. 23 6月, 2009 1 次提交
  15. 26 11月, 2008 2 次提交
  16. 30 10月, 2008 1 次提交
  17. 29 10月, 2008 1 次提交
  18. 27 7月, 2008 1 次提交
    • D
      ipcomp: Fix warnings after ipcomp consolidation. · 2c3abab7
      David S. Miller 提交于
      net/ipv4/ipcomp.c: In function ‘ipcomp4_init_state’:
      net/ipv4/ipcomp.c:109: warning: unused variable ‘calg_desc’
      net/ipv4/ipcomp.c:108: warning: unused variable ‘ipcd’
      net/ipv4/ipcomp.c:107: warning: ‘err’ may be used uninitialized in this function
      net/ipv6/ipcomp6.c: In function ‘ipcomp6_init_state’:
      net/ipv6/ipcomp6.c:139: warning: unused variable ‘calg_desc’
      net/ipv6/ipcomp6.c:138: warning: unused variable ‘ipcd’
      net/ipv6/ipcomp6.c:137: warning: ‘err’ may be used uninitialized in this function
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c3abab7
  19. 25 7月, 2008 1 次提交
  20. 19 4月, 2008 1 次提交
  21. 29 2月, 2008 1 次提交
  22. 01 2月, 2008 2 次提交
  23. 29 1月, 2008 1 次提交
    • H
      [IPSEC]: Forbid BEET + ipcomp for now · e40b3286
      Herbert Xu 提交于
      While BEET can theoretically work with IPComp the current code can't
      do that because it tries to construct a BEET mode tunnel type which
      doesn't (and cannot) exist.  In fact as it is it won't even attach a
      tunnel object at all for BEET which is bogus.
      
      To support this fully we'd also need to change the policy checks on
      input to recognise a plain tunnel as a legal variant of an optional
      BEET transform.
      
      This patch simply fails such constructions for now.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e40b3286
  24. 07 11月, 2007 1 次提交
  25. 02 11月, 2007 1 次提交
  26. 18 10月, 2007 1 次提交
  27. 11 10月, 2007 5 次提交
  28. 11 7月, 2007 1 次提交
  29. 26 4月, 2007 4 次提交