1. 02 5月, 2013 16 次提交
  2. 20 4月, 2013 4 次提交
  3. 19 4月, 2013 2 次提交
  4. 18 4月, 2013 1 次提交
  5. 17 4月, 2013 1 次提交
    • E
      net: drop dst before queueing fragments · 97599dc7
      Eric Dumazet 提交于
      Commit 4a94445c (net: Use ip_route_input_noref() in input path)
      added a bug in IP defragmentation handling, as non refcounted
      dst could escape an RCU protected section.
      
      Commit 64f3b9e2 (net: ip_expire() must revalidate route) fixed
      the case of timeouts, but not the general problem.
      
      Tom Parkin noticed crashes in UDP stack and provided a patch,
      but further analysis permitted us to pinpoint the root cause.
      
      Before queueing a packet into a frag list, we must drop its dst,
      as this dst has limited lifetime (RCU protected)
      
      When/if a packet is finally reassembled, we use the dst of the very
      last skb, still protected by RCU and valid, as the dst of the
      reassembled packet.
      
      Use same logic in IPv6, as there is no need to hold dst references.
      Reported-by: NTom Parkin <tparkin@katalix.com>
      Tested-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97599dc7
  6. 16 4月, 2013 2 次提交
  7. 15 4月, 2013 1 次提交
    • C
      ipv6: statically link register_inet6addr_notifier() · f88c91dd
      Cong Wang 提交于
      Tomas reported the following build error:
      
      net/built-in.o: In function `ieee80211_unregister_hw':
      (.text+0x10f0e1): undefined reference to `unregister_inet6addr_notifier'
      net/built-in.o: In function `ieee80211_register_hw':
      (.text+0x10f610): undefined reference to `register_inet6addr_notifier'
      make: *** [vmlinux] Error 1
      
      when built IPv6 as a module.
      
      So we have to statically link these symbols.
      Reported-by: NTomas Melin <tomas.melin@iki.fi>
      Cc: Tomas Melin <tomas.melin@iki.fi>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YOSHIFUJI Hidaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f88c91dd
  8. 13 4月, 2013 1 次提交
  9. 12 4月, 2013 3 次提交
    • F
      netfilter: nf_nat: fix race when unloading protocol modules · c2d421e1
      Florian Westphal 提交于
      following oops was reported:
      RIP: 0010:[<ffffffffa03227f2>]  [<ffffffffa03227f2>] nf_nat_cleanup_conntrack+0x42/0x70 [nf_nat]
      RSP: 0018:ffff880202c63d40  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8801ac7bec28 RCX: ffff8801d0eedbe0
      RDX: dead000000200200 RSI: 0000000000000011 RDI: ffffffffa03265b8
      [..]
      Call Trace:
       [..]
       [<ffffffffa02febed>] destroy_conntrack+0xbd/0x110 [nf_conntrack]
      
      Happens when a conntrack timeout expires right after first part
      of the nat cleanup has completed (bysrc hash removal), but before
      part 2 has completed (re-initialization of nat area).
      
      [ destroy callback tries to delete bysrc again ]
      
      Patrick suggested to just remove the affected conntracks -- the
      connections won't work properly anyway without nat transformation.
      
      So, lets do that.
      Reported-by: NCAI Qian <caiqian@redhat.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      c2d421e1
    • T
      tcp: Reallocate headroom if it would overflow csum_start · 50bceae9
      Thomas Graf 提交于
      If a TCP retransmission gets partially ACKed and collapsed multiple
      times it is possible for the headroom to grow beyond 64K which will
      overflow the 16bit skb->csum_start which is based on the start of
      the headroom. It has been observed rarely in the wild with IPoIB due
      to the 64K MTU.
      
      Verify if the acking and collapsing resulted in a headroom exceeding
      what csum_start can cover and reallocate the headroom if so.
      
      A big thank you to Jim Foraker <foraker1@llnl.gov> and the team at
      LLNL for helping out with the investigation and testing.
      Reported-by: NJim Foraker <foraker1@llnl.gov>
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50bceae9
    • D
      tcp: incoming connections might use wrong route under synflood · d66954a0
      Dmitry Popov 提交于
      There is a bug in cookie_v4_check (net/ipv4/syncookies.c):
      	flowi4_init_output(&fl4, 0, sk->sk_mark, RT_CONN_FLAGS(sk),
      			   RT_SCOPE_UNIVERSE, IPPROTO_TCP,
      			   inet_sk_flowi_flags(sk),
      			   (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
      			   ireq->loc_addr, th->source, th->dest);
      
      Here we do not respect sk->sk_bound_dev_if, therefore wrong dst_entry may be
      taken. This dst_entry is used by new socket (get_cookie_sock ->
      tcp_v4_syn_recv_sock), so its packets may take the wrong path.
      Signed-off-by: NDmitry Popov <dp@highloadlab.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d66954a0
  10. 11 4月, 2013 1 次提交
    • J
      mac80211: fix cfg80211 interaction on auth/assoc request · 7b119dc0
      Johannes Berg 提交于
      If authentication (or association with FT) is requested by
      userspace, mac80211 currently doesn't tell cfg80211 that it
      disconnected from the AP. That leaves inconsistent state:
      cfg80211 thinks it's connected while mac80211 thinks it's
      not. Typically this won't last long, as soon as mac80211
      reports the new association to cfg80211 the old one goes
      away. If, however, the new authentication or association
      doesn't succeed, then cfg80211 will forever think the old
      one still exists and will refuse attempts to authenticate
      or associate with the AP it thinks it's connected to.
      
      Anders reported that this leads to it taking a very long
      time to reconnect to a network, or never even succeeding.
      I tested this with an AP hacked to never respond to auth
      frames, and one that works, and with just those two the
      system never recovers because one won't work and cfg80211
      thinks it's connected to the other so refuses connections
      to it.
      
      To fix this, simply make mac80211 tell cfg80211 when it is
      no longer connected to the old AP, while authenticating or
      associating to a new one.
      
      Cc: stable@vger.kernel.org
      Reported-by: NAnders Kaseorg <andersk@mit.edu>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7b119dc0
  11. 10 4月, 2013 3 次提交
  12. 09 4月, 2013 5 次提交