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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 30 Nov 2019 02:51:19 +0000 From: subashab@...eaurora.org To: Eric Dumazet <eric.dumazet@...il.com>, Josh Hunt <johunt@...mai.com> Cc: Neal Cardwell <ncardwell@...gle.com>, Netdev <netdev@...r.kernel.org>, Yuchung Cheng <ycheng@...gle.com> Subject: Re: Crash when receiving FIN-ACK in TCP_FIN_WAIT1 state >>> Since tcp_write_queue_purge() calls tcp_rtx_queue_purge() and we're >>> deleting everything in the retrans queue there, doesn't it make sense >>> to zero out all of those associated counters? Obviously clearing >>> sacked_out is helping here, but is there a reason to keep track of >>> lost_out, retrans_out, etc if retrans queue is now empty? Maybe >>> calling tcp_clear_retrans() from tcp_rtx_queue_purge() ? >> >> First, I would like to understand if we hit this problem on current >> upstream kernels. >> >> Maybe a backport forgot a dependency. >> >> tcp_write_queue_purge() calls tcp_clear_all_retrans_hints(), not >> tcp_clear_retrans(), >> this is probably for a reason. >> >> Brute force clearing these fields might hide a serious bug. >> > > I guess we are all too busy to get more understanding on this :/ Our test devices are on 4.19.x and it is not possible to switch to a newer version. Perhaps Josh has seen this on a newer kernel.
Powered by blists - more mailing lists