netdev - Re: [PATCH net] tcp: fix to update snd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Oct 2020 13:04:04 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Apollon Oikonomopoulos <apoikos@...sg.gr>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net] tcp: fix to update snd_wl1 in bulk receiver fast path

On Thu, Oct 22, 2020 at 12:08 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 22 Oct 2020 10:33:31 -0400 Neal Cardwell wrote:
> > From: Neal Cardwell <ncardwell@...gle.com>
> >
> > In the header prediction fast path for a bulk data receiver, if no
> > data is newly acknowledged then we do not call tcp_ack() and do not
> > call tcp_ack_update_window(). This means that a bulk receiver that
> > receives large amounts of data can have the incoming sequence numbers
> > wrap, so that the check in tcp_may_update_window fails:
> >    after(ack_seq, tp->snd_wl1)
> >
> > If the incoming receive windows are zero in this state, and then the
> > connection that was a bulk data receiver later wants to send data,
> > that connection can find itself persistently rejecting the window
> > updates in incoming ACKs. This means the connection can persistently
> > fail to discover that the receive window has opened, which in turn
> > means that the connection is unable to send anything, and the
> > connection's sending process can get permanently "stuck".
> >
> > The fix is to update snd_wl1 in the header prediction fast path for a
> > bulk data receiver, so that it keeps up and does not see wrapping
> > problems.
> >
> > This fix is based on a very nice and thorough analysis and diagnosis
> > by Apollon Oikonomopoulos (see link below).
> >
> > This is a stable candidate but there is no Fixes tag here since the
> > bug predates current git history. Just for fun: looks like the bug
> > dates back to when header prediction was added in Linux v2.1.8 in Nov
> > 1996. In that version tcp_rcv_established() was added, and the code
> > only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
> > receiver" code path it does not call tcp_ack(). This fix seems to
> > apply cleanly at least as far back as v3.2.
>
> In that case - can I slap:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> on it?

Yes, slapping that Fixes footer on it sounds fine to me. I see
that it does apply cleanly to 1da177e4c3f4.

Or let me know if you would prefer for me to resubmit a v2 with that footer.

thanks,
neal