Hi. I probably will succeed installing a given kernel from backports. OTOH I've never messed with unstable (I have never though on bring a kernel to a stable system).
Notice though that I CAN FULLY REPRODUCE the exact same issue on oldstable Bookworm: Until 6.1.0-42, iptables connection limit DoS rule worked as always did, whereas from 6.1.0-43 upgrading results in unusable networking. commenting out the rule and reloading iptables makes networking work again. Will report as (if) I have something. Cheers. On Wed, 2026-03-11 at 17:12 +0100, Salvatore Bonaccorso wrote: > 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
