netdev - Re: [PATCH net] tcp: fix forever orphan socket caused by 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKD1Yr2rqFdtCNmvacEvd_DR3nGVo8+7+sbGPU=g6Gr45T9TQQ@mail.gmail.com>
Date: Wed, 14 Aug 2024 13:43:32 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Jason Xing <kerneljasonxing@...il.com>, Xueming Feng <kuro@...oa.me>, 
	"David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org, 
	Neal Cardwell <ncardwell@...gle.com>, Yuchung Cheng <ycheng@...gle.com>, 
	Soheil Hassas Yeganeh <soheil@...gle.com>, David Ahern <dsahern@...nel.org>, linux-kernel@...r.kernel.org, 
	Maciej Żenczykowski <zenczykowski@...il.com>
Subject: Re: [PATCH net] tcp: fix forever orphan socket caused by tcp_abort

On Mon, Aug 5, 2024 at 4:23 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > Each time we call inet_csk_destroy_sock(), we must make sure we've
> > already set the state to TCP_CLOSE. Based on this, I think we can use
> > this as an indicator to avoid calling twice to destroy the socket.
>
> I do not think this will work.
>
> With this patch, a listener socket will not get an error notification.
>
> Ideally we need tests for this seldom used feature.

FWIW there is a fair amount of test coverage here:

https://cs.android.com/android/platform/superproject/main/+/main:kernel/tests/net/test/sock_diag_test.py

though unfortunately they don't pass on unmodified kernels (I didn't
look into why - maybe Maciej knows). I ran the tests on the "v2-ish
patch" and they all passed except for a test that expects that
SOCK_DESTROY on a FIN_WAIT1 socket does nothing. That seems OK because
it's the thing your patch is trying to fix.

Just to confirm - it's OK to send a RST on a connection that's already
in FIN_WAIT1 state? Is that allowed by the RFC?