netdev - Re: [PATCH net-next] tcp: accept bare FIN packets under memory pressure

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADVnQy=+5-Hkz9Ud0Vy34wJmdQhUB47QujkQrCbXRKi3yq3STA@mail.gmail.com>
Date: Tue, 16 Apr 2024 15:43:50 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, eric.dumazet@...il.com, 
	Andrew Oates <aoates@...gle.com>, Christoph Paasch <cpaasch@...le.com>, Vidhi Goel <vidhi_goel@...le.com>
Subject: Re: [PATCH net-next] tcp: accept bare FIN packets under memory pressure

On Tue, Apr 16, 2024 at 5:50 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> Andrew Oates reported that some macOS hosts could repeatedly
> send FIN packets even if the remote peer drops them and
> send back DUP ACK RWIN 0 packets.
>
> <quoting Andrew>
>
>  20:27:16.968254 gif0  In  IP macos > victim: Flags [SEW], seq 1950399762, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 501897188 ecr 0,sackOK,eol], length 0
>  20:27:16.968339 gif0  Out IP victim > macos: Flags [S.E], seq 2995489058, ack 1950399763, win 1448, options [mss 1460,sackOK,TS val 3829877593 ecr 501897188,nop,wscale 0], length 0
>  20:27:16.968833 gif0  In  IP macos > victim: Flags [.], ack 1, win 2058, options [nop,nop,TS val 501897188 ecr 3829877593], length 0
>  20:27:16.968885 gif0  In  IP macos > victim: Flags [P.], seq 1:1449, ack 1, win 2058, options [nop,nop,TS val 501897188 ecr 3829877593], length 1448
>  20:27:16.968896 gif0  Out IP victim > macos: Flags [.], ack 1449, win 0, options [nop,nop,TS val 3829877593 ecr 501897188], length 0
>  20:27:19.454593 gif0  In  IP macos > victim: Flags [F.], seq 1449, ack 1, win 2058, options [nop,nop,TS val 501899674 ecr 3829877593], length 0
>  20:27:19.454675 gif0  Out IP victim > macos: Flags [.], ack 1449, win 0, options [nop,nop,TS val 3829880079 ecr 501899674], length 0
>  20:27:19.455116 gif0  In  IP macos > victim: Flags [F.], seq 1449, ack 1, win 2058, options [nop,nop,TS val 501899674 ecr 3829880079], length 0
>
>  The retransmits/dup-ACKs then repeat in a tight loop.
>
> </quoting Andrew>
>
> RFC 9293 3.4. Sequence Numbers states :
>
>   Note that when the receive window is zero no segments should be
>   acceptable except ACK segments.  Thus, it is be possible for a TCP to
>   maintain a zero receive window while transmitting data and receiving
>   ACKs.  However, even when the receive window is zero, a TCP must
>   process the RST and URG fields of all incoming segments.
>
> Even if we could consider a bare FIN.ACK packet to be an ACK in RFC terms,
> the retransmits should use exponential backoff.
>
> Accepting the FIN in linux does not add extra memory costs,
> because the FIN flag will simply be merged to the tail skb in
> the receive queue, and incoming packet is freed.
>
> Reported-by: Andrew Oates <aoates@...gle.com>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Neal Cardwell <ncardwell@...gle.com>
> Cc: Christoph Paasch <cpaasch@...le.com>
> Cc: Vidhi Goel <vidhi_goel@...le.com>
> ---

Acked-by: Neal Cardwell <ncardwell@...gle.com>

Thanks, Eric!

neal