• Herbert Xu's avatar
    [TCP]: Clear stale pred_flags when snd_wnd changes · 2ad41065
    Herbert Xu authored
    This bug is responsible for causing the infamous "Treason uncloaked"
    messages that's been popping up everywhere since the printk was added.
    It has usually been blamed on foreign operating systems.  However,
    some of those reports implicate Linux as both systems are running
    Linux or the TCP connection is going across the loopback interface.
    
    In fact, there really is a bug in the Linux TCP header prediction code
    that's been there since at least 2.1.8.  This bug was tracked down with
    help from Dale Blount.
    
    The effect of this bug ranges from harmless "Treason uncloaked"
    messages to hung/aborted TCP connections.  The details of the bug
    and fix is as follows.
    
    When snd_wnd is updated, we only update pred_flags if
    tcp_fast_path_check succeeds.  When it fails (for example,
    when our rcvbuf is used up), we will leave pred_flags with
    an out-of-date snd_wnd value.
    
    When the out-of-date pred_flags happens to match the next incoming
    packet we will again hit the fast path and use the current snd_wnd
    which will be wrong.
    
    In the case of the treason messages, it just happens that the snd_wnd
    cached in pred_flags is zero while tp->snd_wnd is non-zero.  Therefore
    when a zero-window packet comes in we incorrectly conclude that the
    window is non-zero.
    
    In fact if the peer continues to send us zero-window pure ACKs we
    will continue making the same mistake.  It's only when the peer
    transmits a zero-window packet with data attached that we get a
    chance to snap out of it.  This is what triggers the treason
    message at the next retransmit timeout.
    Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
    2ad41065
tcp_input.c 124 KB