netdev - Re: Crash when receiving FIN-ACK in TCP_FIN

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 29 Nov 2019 21:39:33 -0800
From:   Avinash Patil <avinashapatil@...il.com>
To:     subashab@...eaurora.org
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Josh Hunt <johunt@...mai.com>,
        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

Hi Eric,

This crash looks quite similar to the one I am experiencing [1] and
reported already.

[1] https://www.spinics.net/lists/netdev/msg611694.html

Thanks,
Avinash

On Fri, Nov 29, 2019 at 6:52 PM <subashab@...eaurora.org> wrote:
>
> >>> 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.