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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 15 Jan 2021 11:03:27 +0800
From:   "Pengcheng Yang" <yangpc@...gsu.com>
To:     "'Eric Dumazet'" <edumazet@...gle.com>,
        "'Jakub Kicinski'" <kuba@...nel.org>
Cc:     "'David Miller'" <davem@...emloft.net>,
        "'netdev'" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] tcp: fix TCP_SKB_CB(skb)->tcp_tw_isn not being used

On Fri, Jan 15, 2021 at 1:12 AM Eric Dumazet <edumazet@...gle.com> wrote:
> 
> On Thu, Jan 14, 2021 at 5:53 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Tue, 29 Dec 2020 05:59:20 +0800 Pengcheng Yang wrote:
> > > TCP_SKB_CB(skb)->tcp_tw_isn contains an ISN, chosen by
> > > tcp_timewait_state_process() , when SYN is received in TIMEWAIT state.
> > > But tcp_tw_isn is not used because it is overwritten by
> > > tcp_v4_restore_cb() after commit eeea10b83a13 ("tcp: add
> > > tcp_v4_fill_cb()/tcp_v4_restore_cb()").
> > >
> > > To fix this case, we record tcp_tw_isn before tcp_v4_restore_cb() and
> > > then set it in tcp_v4_fill_cb(). V6 does the same.
> > >
> > > Fixes: eeea10b83a13 ("tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()")
> > > Reported-by: chenc <chenc9@...gsu.com>
> > > Signed-off-by: Pengcheng Yang <yangpc@...gsu.com>
> >
> > Please fix the date and resend. This patch came in last night,
> > but it has a date of December 28th.
> 
> Not this whole madness about tcp_v4_fill_cb()/tcp_v4_restore_cb()
> could be reverted

This makes isn always been 0 in tcp_conn_request(), because tcp_tw_isn
is always initialized to 0 in tcp_v4_fill_cb() and tcp_tw_isn becomes meaningless.
Do we need to make tcp_tw_isn work again?

> now we have an RB tree for out-of-order packets.

I don't quite understand how setting tcp_tw_isn for SYN would affect
out_of_order_queue?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ