Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 11月, 2014 1 次提交
    • J
      net: esp: Convert NETDEBUG to pr_info · 45083497
      由 Joe Perches 提交于 
      Commit 64ce2073 ("[NET]: Make NETDEBUG pure printk wrappers")
originally had these NETDEBUG printks as always emitting.

Commit a2a316fd ("[NET]: Replace CONFIG_NET_DEBUG with sysctl")
added a net_msg_warn sysctl to these NETDEBUG uses.

Convert these NETDEBUG uses to normal pr_info calls.

This changes the output prefix from "ESP: " to include
"IPSec: " for the ipv4 case and "IPv6: " for the ipv6 case.

These output lines are now like the other messages in the files.

Other miscellanea:

Neaten the arithmetic spacing to be consistent with other
arithmetic spacing in the files.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45083497
  3. 25 8月, 2014 2 次提交
  5. 14 3月, 2014 1 次提交
  7. 07 12月, 2013 1 次提交
  9. 29 10月, 2013 2 次提交
  11. 16 9月, 2013 1 次提交
  13. 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
  15. 06 8月, 2013 1 次提交
    • D
      net: esp{4,6}: fix potential MTU calculation overflows · 7921895a
      由 Daniel Borkmann 提交于 
      Commit 91657eaf ("xfrm: take net hdr len into account for esp payload
size calculation") introduced a possible interger overflow in
esp{4,6}_get_mtu() handlers in case of x->props.mode equals
XFRM_MODE_TUNNEL. Thus, the following expression will overflow

  unsigned int net_adj;
  ...
  <case ipv{4,6} XFRM_MODE_TUNNEL>
         net_adj = 0;
  ...
  return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
           net_adj) & ~(align - 1)) + (net_adj - 2);

where (net_adj - 2) would be evaluated as <foo> + (0 - 2) in an unsigned
context. Fix it by simply removing brackets as those operations here
do not need to have special precedence.
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Cc: Benjamin Poirier <bpoirier@suse.de>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: NBenjamin Poirier <bpoirier@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7921895a
  17. 08 1月, 2013 1 次提交
  19. 01 9月, 2012 1 次提交
  21. 12 7月, 2012 1 次提交
  23. 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
  25. 27 5月, 2012 1 次提交
  27. 16 5月, 2012 2 次提交
  29. 27 4月, 2011 1 次提交
  31. 23 4月, 2011 1 次提交
  33. 14 3月, 2011 2 次提交
  35. 11 12月, 2010 1 次提交
  37. 23 2月, 2010 1 次提交
  39. 26 11月, 2009 1 次提交
  41. 15 9月, 2009 1 次提交
  43. 23 6月, 2009 1 次提交
  45. 26 11月, 2008 2 次提交
  47. 30 10月, 2008 1 次提交
  49. 29 10月, 2008 1 次提交
  51. 06 8月, 2008 1 次提交
  53. 28 3月, 2008 1 次提交
  55. 13 2月, 2008 1 次提交
  57. 01 2月, 2008 3 次提交
  59. 29 1月, 2008 4 次提交