Control: tags -1 + moreinfo upstream Hi Alejandro,
On Wed, Mar 11, 2026 at 04:07:47PM +0100, Alejandro Oliván Alvarez wrote: > So, by reading git bisect final output: > > b29ddccf36946a90323486221f39e9f88cc01b8e is the first bad commit > commit b29ddccf36946a90323486221f39e9f88cc01b8e > Author: Fernando Fernandez Mancera <[email protected]> > Date: Fri Nov 21 01:14:32 2025 +0100 > > netfilter: nft_connlimit: update the count if add was skipped > > [ Upstream commit 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e ] > > Connlimit expression can be used for all kind of packets and not > only > for packets with connection state new. See this ruleset as example: > > table ip filter { > chain input { > type filter hook input priority filter; policy > accept; > tcp dport 22 ct count over 4 counter > } > } > > Currently, if the connection count goes over the limit the counter > will > count the packets. When a connection is closed, the connection > count > won't decrement as it should because it is only updated for new > connections due to an optimization on __nf_conncount_add() that > prevents > updating the list if the connection is duplicated. > > To solve this problem, check whether the connection was skipped and > if > so, update the list. Adjust count_tree() too so the same fix is > applied > for xt_connlimit. > > Fixes: 976afca1ceba ("netfilter: nf_conncount: Early exit in > nf_conncount_lookup() and cleanup") > Closes: > https://lore.kernel.org/netfilter/trinity-85c72a88-d762-46c3-be97-36f10e5d9796-1761173693813@3c-app-mailcom-bs12/ > Signed-off-by: Fernando Fernandez Mancera <[email protected]> > Signed-off-by: Pablo Neira Ayuso <[email protected]> > Signed-off-by: Sasha Levin <[email protected]> > > net/netfilter/nf_conncount.c | 12 ++++++++---- > net/netfilter/nft_connlimit.c | 13 +++++++++++-- > 2 files changed, 19 insertions(+), 6 deletions(-) > > > I got the clue that the issue seems related to netfilter connection > count/track limit. > Effectively, I do use in my iptables scripts de connection limit > feature to deal with some DoS activity. > > > I can assert that by just commenting the following iptables line on my > scripts: > > iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j > REJECT --reject-with tcp-reset > > And reloading the rules, networking resumes working normally with > latest 6.12.73 kernel (and presumably with all of them in between). > Still, this iptables rule has worked nicely for me for years. > Not sure whether I should dismiss it from now on, since this is the > intended way for the kernel to work, or there is, indeed, something > wrong on the kernel Thank you for having done this bisect work and identify the commit in combination with the given rule. Might I ask you one latest test do perform? The commit 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") was backported from 6.19-rc1 to the various stable series (in particular 6.18.2, 6.17.13 as well): Can you either test 6.17.13-1~bpo13+1 from backports, and ideally as well 6.19.6 from unstable to see if the problem reproduces htere as well with a newer kernel which did include this change as well? Regards, Salvatore
