netdev - Re: [PATCH net-next] tcp: fix TCP

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:   Thu, 18 Oct 2018 16:51:39 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     edumazet@...gle.com
Cc:     ncardwell@...gle.com, soheil@...gle.com, avagin@...nvz.org,
        netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next] tcp: fix TCP_REPAIR xmit queue setup

From: Eric Dumazet <edumazet@...gle.com>
Date: Thu, 18 Oct 2018 09:12:19 -0700

> Andrey reported the following warning triggered while running CRIU tests:
> 
> tcp_clean_rtx_queue()
> ...
> 	last_ackt = tcp_skb_timestamp_us(skb);
> 	WARN_ON_ONCE(last_ackt == 0);
> 
> This is caused by 5f6188a8003d ("tcp: do not change tcp_wstamp_ns
> in tcp_mstamp_refresh"), as we end up having skbs in retransmit queue
> with a zero skb->skb_mstamp_ns field.
> 
> We could fix this bug in different ways, like making sure
> tp->tcp_wstamp_ns is not zero at socket creation, but as Neal pointed
> out, we also do not want that pacing status of a repaired socket
> could push tp->tcp_wstamp_ns far ahead in the future.
> 
> So we prefer changing tcp_write_xmit() to not call tcp_update_skb_after_send()
> and instead do what is requested by TCP_REPAIR logic.
> 
> Fixes: 5f6188a8003d ("tcp: do not change tcp_wstamp_ns in tcp_mstamp_refresh")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Reported-by: Andrey Vagin <avagin@...nvz.org>
> Acked-by: Soheil Hassas Yeganeh <soheil@...gle.com>
> Acked-by: Neal Cardwell <ncardwell@...gle.com>

Applied, thanks Eric.