linux-kernel - Re: [bug report, linux 6.15-rc4] A large number of connections in the SYN_SENT state caused the nf

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: <c9255252-3b6a-886a-5959-d59d0bb4640e@blackhole.kfki.hu>
Date: Wed, 28 May 2025 16:18:25 +0200 (CEST)
From: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
To: ying chen <yc1082463@...il.com>
cc: Eric Dumazet <edumazet@...gle.com>, Florian Westphal <fw@...len.de>, 
    pablo@...filter.org, kadlec@...filter.org, davem@...emloft.net, 
    kuba@...nel.org, pabeni@...hat.com, netfilter-devel@...r.kernel.org, 
    coreteam@...filter.org, netdev@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [bug report, linux 6.15-rc4] A large number of connections in
 the SYN_SENT state caused the nf_conntrack table to be full.

On Wed, 28 May 2025, ying chen wrote:

> On Wed, May 28, 2025 at 9:45 PM Jozsef Kadlecsik
> <kadlec@...ckhole.kfki.hu> wrote:
>>
>> On Wed, 28 May 2025, Eric Dumazet wrote:
>>
>>> On Wed, May 28, 2025 at 6:26 AM ying chen <yc1082463@...il.com> wrote:
>>>>
>>>> On Wed, May 28, 2025 at 9:10 PM Florian Westphal <fw@...len.de> wrote:
>>>>>
>>>>> ying chen <yc1082463@...il.com> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I encountered an "nf_conntrack: table full" warning on Linux 6.15-rc4.
>>>>>> Running cat /proc/net/nf_conntrack showed a large number of
>>>>>> connections in the SYN_SENT state.
>>>>>> As is well known, if we attempt to connect to a non-existent port, the
>>>>>> system will respond with an RST and then delete the conntrack entry.
>>>>>> However, when we frequently connect to non-existent ports, the
>>>>>> conntrack entries are not deleted, eventually causing the nf_conntrack
>>>>>> table to fill up.
>>>>>
>>>>> Yes, what do you expect to happen?
>>>> I understand that the conntrack entry should be deleted immediately
>>>> after receiving the RST reply.
>>>
>>> Then it probably hints that you do not receive RST for all your SYN
>>> packets.
>>
>> And Eric has got right: because the states are in SYN_SENT then either the
>> RST packets were not received or out of the window or invalid from other
>> reasons.
> I also suspect it's due to being "out of the window", but I'm not sure why.

tcpdump of the traffic from the targeted machine with both the SYN and RST 
packets could help (raw pcap or at least the output with absolute seqs).

Best regards,
Jozsef