1. 09 Feb, 2015 34 commits
  2. 08 Feb, 2015 6 commits
    • Jon Paul Maloy's avatar
      tipc: fix bug in socket reception function · 51a00daf
      Jon Paul Maloy authored
      In commit c637c103 ("tipc: resolve race
      problem at unicast message reception") we introduced a time limit
      for how long the function tipc_sk_eneque() would be allowed to execute
      its loop. Unfortunately, the test for when this limit is passed was put
      in the wrong place, resulting in a lost message when the test is true.
      
      We fix this by moving the test to before we dequeue the next buffer
      from the input queue.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51a00daf
    • Michael Büsch's avatar
      rt6_probe_deferred: Do not depend on struct ordering · 662f5533
      Michael Büsch authored
      rt6_probe allocates a struct __rt6_probe_work and schedules a work handler rt6_probe_deferred.
      But rt6_probe_deferred kfree's the struct work_struct instead of struct __rt6_probe_work.
      This works, because struct work_struct is the first element of struct __rt6_probe_work.
      
      Change it to kfree struct __rt6_probe_work to not implicitly depend on
      struct work_struct being the first element.
      
      This does not affect the generated code.
      Signed-off-by: default avatarMichael Buesch <m@bues.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      662f5533
    • David S. Miller's avatar
      Merge branch 'tcp_ack_loops' · f06535c5
      David S. Miller authored
      Neal Cardwellsays:
      
      ====================
      tcp: mitigate TCP ACK loops due to out-of-window validation dupacks
      
      This patch series mitigates "ack loop" DoS scenarios by rate-limiting
      outgoing duplicate ACKs sent in response to incoming "out of window"
      segments.
      
      Background
      -----------
      
      There are several cases in which the TCP RFCs specify that a TCP
      endpoint should send a pure duplicate ACK in response to a pure
      duplicate ACK that appears to be invalid due to being "out of window":
      
      (1) RFC 793 (section 3.9, page 69) specifies that endpoints should
          send a duplicate ACK in response to an ACK when the incoming
          sequence number is invalid due to being outside the receive
          window: "If an incoming segment is not acceptable, an
          acknowledgment should be sent in reply".
      
      (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges
          something not yet sent (SEG.ACK > SND.NXT) then send an ACK".
      
      (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should
          send a duplicate ACK in response to an ACK when the PAWS check for
          the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent
          and if TS.Recent is valid ... Send an acknowledgement in reply"
      
      The problem
      ------------
      
      Normally, this is not a problem. However, a buggy middlebox or
      malicious man-in-the-middle can inject a few packets into the
      conversation that advance each endpoint's notion of the current window
      (sequence, ACK, or timestamp), without either side noticing. In this
      case, from then on each side can think the other is sending invalid
      segments. Thus an infinite feedback loop of duplicate ACKs can ensue,
      as each endpoint receives a duplicate ACK, decides that it is invalid
      (due to sequence number, ACK number, or timestamp), and then sends a
      dupack in reply, which the other side decides is invalid, responding
      with a dupack... ad infinitum. This ping-pong feedback loop can happen
      at a very high rate.
      
      This phenomenon can and does happen in practice. It has been seen in
      datacenter and Internet contexts at Google, and has been documented by
      Anil Agarwal in the Nov 2013 tcpm thread "TCP mismatched sequence
      numbers issue", and Avery Fay in the Feb 2015 Linux netdev thread
      "Invalid timestamp? causing tight ack loop (hundreds of thousands of
      packets / sec)".
      
      This patch series
      ------------------
      
      This patch series mitigates such ack loops by rate-limiting outgoing
      duplicate ACKs sent in response to incoming TCP packets that are for
      an existing connection but that are invalid due to any of the reasons
      mentioned above: sequence number (1), ACK field (2), or timestamp
      value (3). The rate limit for such duplicate ACKs is specified by a
      new sysctl, tcp_invalid_ratelimit, which specifies the minimal space
      between such outbound duplicate ACKs, in milliseconds. The default is
      500 (500ms), and 0 disables the mechanism.
      
      We rate-limit these duplicate ACK responses rather than blocking them
      entirely or resetting the connection, because legitimate connections
      can rely on dupacks in response to some out-of-window segments. For
      example, zero window probes are typically sent with a sequence number
      that is below the current window, and ZWPs thus expect to thus elicit
      a dupack in response.
      
      Testing: this approach has been in use at Google for a while.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f06535c5
    • Neal Cardwell's avatar
      tcp: mitigate ACK loops for connections as tcp_timewait_sock · 4fb17a60
      Neal Cardwell authored
      Ensure that in state FIN_WAIT2 or TIME_WAIT, where the connection is
      represented by a tcp_timewait_sock, we rate limit dupacks in response
      to incoming packets (a) with TCP timestamps that fail PAWS checks, or
      (b) with sequence numbers that are out of the acceptable window.
      
      We do not send a dupack in response to out-of-window packets if it has
      been less than sysctl_tcp_invalid_ratelimit (default 500ms) since we
      last sent a dupack in response to an out-of-window packet.
      Reported-by: default avatarAvery Fay <avery@mixpanel.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fb17a60
    • Neal Cardwell's avatar
      tcp: mitigate ACK loops for connections as tcp_sock · f2b2c582
      Neal Cardwell authored
      Ensure that in state ESTABLISHED, where the connection is represented
      by a tcp_sock, we rate limit dupacks in response to incoming packets
      (a) with TCP timestamps that fail PAWS checks, or (b) with sequence
      numbers or ACK numbers that are out of the acceptable window.
      
      We do not send a dupack in response to out-of-window packets if it has
      been less than sysctl_tcp_invalid_ratelimit (default 500ms) since we
      last sent a dupack in response to an out-of-window packet.
      
      There is already a similar (although global) rate-limiting mechanism
      for "challenge ACKs". When deciding whether to send a challence ACK,
      we first consult the new per-connection rate limit, and then the
      global rate limit.
      Reported-by: default avatarAvery Fay <avery@mixpanel.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2b2c582
    • Neal Cardwell's avatar
      tcp: mitigate ACK loops for connections as tcp_request_sock · a9b2c06d
      Neal Cardwell authored
      In the SYN_RECV state, where the TCP connection is represented by
      tcp_request_sock, we now rate-limit SYNACKs in response to a client's
      retransmitted SYNs: we do not send a SYNACK in response to client SYN
      if it has been less than sysctl_tcp_invalid_ratelimit (default 500ms)
      since we last sent a SYNACK in response to a client's retransmitted
      SYN.
      
      This allows the vast majority of legitimate client connections to
      proceed unimpeded, even for the most aggressive platforms, iOS and
      MacOS, which actually retransmit SYNs 1-second intervals for several
      times in a row. They use SYN RTO timeouts following the progression:
      1,1,1,1,1,2,4,8,16,32.
      Reported-by: default avatarAvery Fay <avery@mixpanel.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9b2c06d