Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 12月, 2013 1 次提交
  3. 29 10月, 2013 2 次提交
  5. 16 9月, 2013 1 次提交
  7. 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
  9. 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
  11. 08 1月, 2013 1 次提交
  13. 01 9月, 2012 1 次提交
  15. 12 7月, 2012 1 次提交
  17. 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
  19. 27 5月, 2012 1 次提交
  21. 16 5月, 2012 2 次提交
  23. 27 4月, 2011 1 次提交
  25. 23 4月, 2011 1 次提交
  27. 14 3月, 2011 2 次提交
  29. 11 12月, 2010 1 次提交
  31. 23 2月, 2010 1 次提交
  33. 26 11月, 2009 1 次提交
  35. 15 9月, 2009 1 次提交
  37. 23 6月, 2009 1 次提交
  39. 26 11月, 2008 2 次提交
  41. 30 10月, 2008 1 次提交
  43. 29 10月, 2008 1 次提交
  45. 06 8月, 2008 1 次提交
  47. 28 3月, 2008 1 次提交
  49. 13 2月, 2008 1 次提交
  51. 01 2月, 2008 3 次提交
  53. 29 1月, 2008 4 次提交
  55. 11 12月, 2007 1 次提交
  57. 31 10月, 2007 1 次提交
    • D
      [NET]: Fix incorrect sg_mark_end() calls. · 51c739d1
      由 David S. Miller 提交于 
      This fixes scatterlist corruptions added by

	commit 68e3f5dd
	[CRYPTO] users: Fix up scatterlist conversion errors

The issue is that the code calls sg_mark_end() which clobbers the
sg_page() pointer of the final scatterlist entry.

The first part fo the fix makes skb_to_sgvec() do __sg_mark_end().

After considering all skb_to_sgvec() call sites the most correct
solution is to call __sg_mark_end() in skb_to_sgvec() since that is
what all of the callers would end up doing anyways.

I suspect this might have fixed some problems in virtio_net which is
the sole non-crypto user of skb_to_sgvec().

Other similar sg_mark_end() cases were converted over to
__sg_mark_end() as well.

Arguably sg_mark_end() is a poorly named function because it doesn't
just "mark", it clears out the page pointer as a side effect, which is
what led to these bugs in the first place.

The one remaining plain sg_mark_end() call is in scsi_alloc_sgtable()
and arguably it could be converted to __sg_mark_end() if only so that
we can delete this confusing interface from linux/scatterlist.h
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51c739d1
  59. 27 10月, 2007 2 次提交