Re: [REGRESSION] 6.19.4 stable netfilter / nftables -> resolved
From: Genes Lists
Date: Fri Feb 27 2026 - 13:59:31 EST
On Fri, 2026-02-27 at 09:13 +0100, Florian Westphal wrote:
> Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> wrote:
> > On 2/27/26 04:46, Genes Lists wrote:
> > > I have a problem with nftables not working on 6.19.4
> >
> > Thx for the report. A problem that from a brief look seems to be
> > similar
> > ist already discussed and was bisected in this thread:
> >
> > https://lore.kernel.org/all/bb9ab61c-3bed-4c3d-baf0-
> > 0bce4e142292@xxxxxxxxxxxxxxxx/
>
> Thanks for this pointer.
>
> Can someone check if 'git cherry-pick
> f175b46d9134f708358b5404730c6dfa200fbf3c'
> makes things work again post 6.19.4?
>
> Its a missing indirect dependency.
Summary now that all is resolved.
There were, coincidently, 2 separate issues.
Pure serendipity they happened together.
a) kernel 6.19.4 netfilter oops [1]
which is fixed by
f175b46d9134f708358b5404730c6dfa200fbf3c
b) nftables with large sets
nft reports spurious error:
rule could not be loaded: File exists
After which no rules are loaded.
Fixed in nftables git repo by commit:
---
commit e83e32c8d1cd228d751fb92b756306c6eb6c0759
Author: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Date: Mon Jan 12 12:59:26 2026 +0100
mnl: restore create element command with large batches
The rework to reduce memory consumption has introduced a
bug that result in spurious EEXIST with large batches.
---
This happens with kernels :
- 6.19.4 + netfilter commit f175b46d9134f7
- 7.0-rc1
- linux-next
It does not seem to happen with older kernels (assuming I
did not mess up the testing!)
I confirmed this 2nd issue is resolved in both
- nftables git head and
- v1.1.6 plus
git cherry-pick \
a9ead6a808dbe637ae7b9f54598f0dff9582d34d \
e83e32c8d1cd228d751fb92b756306c6eb6c0759
thanks all.
gene
[1]
https://lore.kernel.org/all/bb9ab61c-3bed-4c3d-baf0-0bce4e142292@xxxxxxxxxxxxxxxx/
Attachment:
signature.asc
Description: This is a digitally signed message part