[REGRESSION] 6.19.4 stable netfilter / nftables

[REGRESSION] 6.19.4 stable netfilter / nftables

[Genes Lists]

[-- Attachment #1.1: Type: text/plain, Size: 5486 bytes --]

I have a problem with nftables not working on 6.19.4 

I apologize for not having done a bisect, but this is on a production
firewall, so a bisect is not practical. If I can reproduce this on non-
prod box, I can do a bisect. Hopefully this is is helpful nonetheless.


Check different kernels with same nftables rules:

 - 6.19.4 (freshly compiled)
   nft fails, and kernel logs trace. 
   boot does not complete if nftables service is enabled.

 - 6.19.3
   nft works fine and nothing bad in logs

 - mainline commit 3f4a08e64442340f4807de63e30aef22cc308830
   nft fails with same error, but no trace in the kernel log.
   boots but without working nftables.

The error nft displays, references somewhere in the middle
of a large set of cidr elements:

  nft: In file included from /etc/nftables.conf:134:2-44:
  nft: ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
        Could not proces rule: File exists
  nft:                     23.157.184.0/23,
  nft:                     ^^^^^^^^^^^^^^^

 Removing all but one element from set and rerunning nft, 
 moves the line number but the error remains.

Userspace Archlinux:
 - nftables 1.1.6
 - libmnl 1.0.5
 - libnftnl 1.3.1
 - gcc 15.2.1+r604+g0b99615a8aef-1
 - binutils 2.46-1

The first sign of trouble in 6.19.4 kernel log is:

[   39.731654] kernel: RIP: 0010:free_large_kmalloc+0xa8/0xd0
[   39.731676] kernel: Code: 8d 78 ff a8 01 48 0f 44 fb eb bb 3d f8 00
00 00 75 18 0f 0b 80 3d 50 ff fd 01 00 0f 84 48 c1 b9 ff ba 00 f0 ff ff
31 ed eb 8d <0f> 0b 48 c7 c6 86 3c 83 96 48 89 df 5b 5d e9 95 9c fa ff
48 83 ef
[   39.731698] kernel: RSP: 0018:ffffd0bcc146b610 EFLAGS: 00010202
[   39.731720] kernel: RAX: 00000000000000ff RBX: fffffa5a04ad8680 RCX:
ffff89c66b61ad40
[   39.731747] kernel: RDX: 0000000000000000 RSI: ffff89c66b61a880 RDI:
fffffa5a04ad8680
[   39.731767] kernel: RBP: ffff89c66b61a880 R08: ffff89c6496ab6f0 R09:
ffff89c66b6229c1
[   39.731787] kernel: R10: ffff89c66b61a880 R11: fffffa5a04ad8680 R12:
ffffd0bcc146b6a0
[   39.731814] kernel: R13: ffff89c6496ab6f0 R14: ffff89c6496ab720 R15:
ffffd0bcc146b6b0
[   39.731836] kernel: FS:  00007bd6c7717c40(0000)
GS:ffff89ca073c7000(0000) knlGS:0000000000000000
[   39.731854] kernel: CS:  0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[   39.731877] kernel: CR2: 0000746430061058 CR3: 0000000105ce4004 CR4:
00000000003726f0
[   39.731903] kernel: Call Trace:
[   39.731926] kernel:  <TASK>
[   39.731993] kernel:  nf_tables_abort_release+0x22f/0x260 [nf_tables
78d597f27a85e5d69246ce15656dd0568c927257]
[   39.732026] kernel:  nf_tables_abort+0x2cd/0xe80 [nf_tables
78d597f27a85e5d69246ce15656dd0568c927257]
[   39.732051] kernel:  nfnetlink_rcv_batch+0x8c3/0xb80 [nfnetlink
938a1b64e36f407a05edbdcd1906670ecd99bb43]
[   39.732076] kernel:  nfnetlink_rcv+0x195/0x1c0 [nfnetlink
938a1b64e36f407a05edbdcd1906670ecd99bb43]
[   39.732101] kernel:  netlink_unicast+0x288/0x3c0
[   39.732126] kernel:  netlink_sendmsg+0x20d/0x430
[   39.732138] kernel:  ____sys_sendmsg+0x388/0x3c0
[   39.732149] kernel:  ? import_iovec+0x1b/0x30
[   39.732160] kernel:  ___sys_sendmsg+0x99/0xe0
[   39.732172] kernel:  __sys_sendmsg+0x8a/0xf0
[   39.732184] kernel:  do_syscall_64+0x81/0x610
[   39.732202] kernel:  ? __handle_mm_fault+0xb46/0xf60
[   39.732228] kernel:  ? perf_event_task_tick+0x4f/0xb0
[   39.732256] kernel:  ? count_memcg_events+0xc2/0x170
[   39.732279] kernel:  ? handle_mm_fault+0x1d7/0x2d0
[   39.732306] kernel:  ? do_user_addr_fault+0x21a/0x690
[   39.732333] kernel:  ? exc_page_fault+0x7e/0x1a0
[   39.732358] kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e


(gdb) list *(nf_tables_abort_release+0x22f/0x260)
0x10c20 is in nf_tables_abort_release
(net/netfilter/nf_tables_api.c:11119).
11114		mutex_lock(&nft_net->commit_mutex);
11115		list_splice(&module_list, &nft_net->module_list);
11116	}
11117	
11118	static void nf_tables_abort_release(struct nft_trans *trans)
11119	{
11120		struct nft_ctx ctx = { };
11121	
11122		nft_ctx_update(&ctx, trans);


After this there are a lot of repeated lines like
[   39.732596] kernel: page: refcount:0 mapcount:0
mapping:0000000000000000 index:0xffff89c66b61a140 pfn:0x12b61a
[   39.733541] kernel: raw: ffff89c66b620180 0000000000400000
00000000ffffffff 0000000000000000
[   39.733738] kernel: raw: ffff89c66b61fc80 0000000000400000
00000000ffffffff 0000000000000000
[   39.733874] kernel: raw: ffff89c66b61fc80 0000000000400000
00000000ffffffff 0000000000000000
[   39.734032] kernel: raw: ffff89c66b61ea40 0000000000400000
00000000ffffffff 0000000000000000
[   39.749164] kernel: flags:
0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[   39.749221] kernel: raw: 0017ffffc0000000 fffffa5a04ad8d88
fffffa5a04ad8d48 0000000000000000
[   39.749243] kernel: raw: ffff89c66b634880 0000000000400000
00000000ffffffff 0000000000000000
[   39.749266] kernel: page dumped because: Not a kmalloc allocation
[   39.749283] kernel: page: refcount:0 mapcount:0
mapping:0000000000000000 index:0xffff89c66b634880 pfn:0x12b634
[   39.749306] kernel: flags:
0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[   39.749329] kernel: raw: 0017ffffc0000000 fffffa5a04ad8d88
fffffa5a04ad8d48 0000000000000000
[   39.749351] kernel: raw: ffff89c66b634880 0000000000400000
00000000ffffffff 0000000000000000
[   39.749372] kernel: page dumped because: Not a kmalloc allocation
...

-- 
Gene

[-- Attachment #1.2: klog-6.19.3 --]
[-- Type: application/x-troff-man, Size: 85878 bytes --]

[-- Attachment #1.3: klog-6.19.4 --]
[-- Type: application/x-troff-man, Size: 231298 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] 6.19.4 stable netfilter / nftables

[Thorsten Leemhuis]

Lo!

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@moonlit-rail.com/

I assume Greg will handle this soon through a revert or by applying
another patch.

Ciao, Thorsten

> I apologize for not having done a bisect, but this is on a production
> firewall, so a bisect is not practical. If I can reproduce this on non-
> prod box, I can do a bisect. Hopefully this is is helpful nonetheless.
> 
> 
> Check different kernels with same nftables rules:
> 
>  - 6.19.4 (freshly compiled)
>    nft fails, and kernel logs trace. 
>    boot does not complete if nftables service is enabled.
> 
>  - 6.19.3
>    nft works fine and nothing bad in logs
> 
>  - mainline commit 3f4a08e64442340f4807de63e30aef22cc308830
>    nft fails with same error, but no trace in the kernel log.
>    boots but without working nftables.
> 
> The error nft displays, references somewhere in the middle
> of a large set of cidr elements:
> 
>   nft: In file included from /etc/nftables.conf:134:2-44:
>   nft: ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
>         Could not proces rule: File exists
>   nft:                     23.157.184.0/23,
>   nft:                     ^^^^^^^^^^^^^^^
> 
>  Removing all but one element from set and rerunning nft, 
>  moves the line number but the error remains.
> 
> Userspace Archlinux:
>  - nftables 1.1.6
>  - libmnl 1.0.5
>  - libnftnl 1.3.1
>  - gcc 15.2.1+r604+g0b99615a8aef-1
>  - binutils 2.46-1
> 
> The first sign of trouble in 6.19.4 kernel log is:
> 
> [   39.731654] kernel: RIP: 0010:free_large_kmalloc+0xa8/0xd0
> [   39.731676] kernel: Code: 8d 78 ff a8 01 48 0f 44 fb eb bb 3d f8 00
> 00 00 75 18 0f 0b 80 3d 50 ff fd 01 00 0f 84 48 c1 b9 ff ba 00 f0 ff ff
> 31 ed eb 8d <0f> 0b 48 c7 c6 86 3c 83 96 48 89 df 5b 5d e9 95 9c fa ff
> 48 83 ef
> [   39.731698] kernel: RSP: 0018:ffffd0bcc146b610 EFLAGS: 00010202
> [   39.731720] kernel: RAX: 00000000000000ff RBX: fffffa5a04ad8680 RCX:
> ffff89c66b61ad40
> [   39.731747] kernel: RDX: 0000000000000000 RSI: ffff89c66b61a880 RDI:
> fffffa5a04ad8680
> [   39.731767] kernel: RBP: ffff89c66b61a880 R08: ffff89c6496ab6f0 R09:
> ffff89c66b6229c1
> [   39.731787] kernel: R10: ffff89c66b61a880 R11: fffffa5a04ad8680 R12:
> ffffd0bcc146b6a0
> [   39.731814] kernel: R13: ffff89c6496ab6f0 R14: ffff89c6496ab720 R15:
> ffffd0bcc146b6b0
> [   39.731836] kernel: FS:  00007bd6c7717c40(0000)
> GS:ffff89ca073c7000(0000) knlGS:0000000000000000
> [   39.731854] kernel: CS:  0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> [   39.731877] kernel: CR2: 0000746430061058 CR3: 0000000105ce4004 CR4:
> 00000000003726f0
> [   39.731903] kernel: Call Trace:
> [   39.731926] kernel:  <TASK>
> [   39.731993] kernel:  nf_tables_abort_release+0x22f/0x260 [nf_tables
> 78d597f27a85e5d69246ce15656dd0568c927257]
> [   39.732026] kernel:  nf_tables_abort+0x2cd/0xe80 [nf_tables
> 78d597f27a85e5d69246ce15656dd0568c927257]
> [   39.732051] kernel:  nfnetlink_rcv_batch+0x8c3/0xb80 [nfnetlink
> 938a1b64e36f407a05edbdcd1906670ecd99bb43]
> [   39.732076] kernel:  nfnetlink_rcv+0x195/0x1c0 [nfnetlink
> 938a1b64e36f407a05edbdcd1906670ecd99bb43]
> [   39.732101] kernel:  netlink_unicast+0x288/0x3c0
> [   39.732126] kernel:  netlink_sendmsg+0x20d/0x430
> [   39.732138] kernel:  ____sys_sendmsg+0x388/0x3c0
> [   39.732149] kernel:  ? import_iovec+0x1b/0x30
> [   39.732160] kernel:  ___sys_sendmsg+0x99/0xe0
> [   39.732172] kernel:  __sys_sendmsg+0x8a/0xf0
> [   39.732184] kernel:  do_syscall_64+0x81/0x610
> [   39.732202] kernel:  ? __handle_mm_fault+0xb46/0xf60
> [   39.732228] kernel:  ? perf_event_task_tick+0x4f/0xb0
> [   39.732256] kernel:  ? count_memcg_events+0xc2/0x170
> [   39.732279] kernel:  ? handle_mm_fault+0x1d7/0x2d0
> [   39.732306] kernel:  ? do_user_addr_fault+0x21a/0x690
> [   39.732333] kernel:  ? exc_page_fault+0x7e/0x1a0
> [   39.732358] kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> 
> (gdb) list *(nf_tables_abort_release+0x22f/0x260)
> 0x10c20 is in nf_tables_abort_release
> (net/netfilter/nf_tables_api.c:11119).
> 11114		mutex_lock(&nft_net->commit_mutex);
> 11115		list_splice(&module_list, &nft_net->module_list);
> 11116	}
> 11117	
> 11118	static void nf_tables_abort_release(struct nft_trans *trans)
> 11119	{
> 11120		struct nft_ctx ctx = { };
> 11121	
> 11122		nft_ctx_update(&ctx, trans);
> 
> 
> After this there are a lot of repeated lines like
> [   39.732596] kernel: page: refcount:0 mapcount:0
> mapping:0000000000000000 index:0xffff89c66b61a140 pfn:0x12b61a
> [   39.733541] kernel: raw: ffff89c66b620180 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.733738] kernel: raw: ffff89c66b61fc80 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.733874] kernel: raw: ffff89c66b61fc80 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.734032] kernel: raw: ffff89c66b61ea40 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.749164] kernel: flags:
> 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
> [   39.749221] kernel: raw: 0017ffffc0000000 fffffa5a04ad8d88
> fffffa5a04ad8d48 0000000000000000
> [   39.749243] kernel: raw: ffff89c66b634880 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.749266] kernel: page dumped because: Not a kmalloc allocation
> [   39.749283] kernel: page: refcount:0 mapcount:0
> mapping:0000000000000000 index:0xffff89c66b634880 pfn:0x12b634
> [   39.749306] kernel: flags:
> 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
> [   39.749329] kernel: raw: 0017ffffc0000000 fffffa5a04ad8d88
> fffffa5a04ad8d48 0000000000000000
> [   39.749351] kernel: raw: ffff89c66b634880 0000000000400000
> 00000000ffffffff 0000000000000000
> [   39.749372] kernel: page dumped because: Not a kmalloc allocation
> ...
> 

Re: [REGRESSION] 6.19.4 stable netfilter / nftables

[Florian Westphal]

Thorsten Leemhuis <regressions@leemhuis.info> 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@moonlit-rail.com/

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.

Re: [REGRESSION] 6.19.4 stable netfilter / nftables

[Genes Lists]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> Lo!
> 
> 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@moonlit-rail.com/
> 
> I assume Greg will handle this soon through a revert or by applying
> another patch.
> 
> Ciao, Thorsten
> 
Thank you Thorsten.

There are 2, possibly related or not, issues. 

  - failure to boot with 6.19.4 (thread you linked above)
  - nft failing to load any rules (mainline) with error message.
 
I responded to that thread since in my case 7.0 mainline boots fine but
nft does not load any rules. 6.19.3 loads the same rules just fine.

Repeating the nft error message here for simplicity:

 Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
  ...
  In file included from /etc/nftables.conf:134:2-44:
  ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
  Could not process rule: File exists
                 xx.xxx.xxx.x/23,
                 ^^^^^^^^^^^^^^^



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Genes Lists]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > Lo!
> > 
> 
> Repeating the nft error message here for simplicity:
> 
>  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
>   ...
>   In file included from /etc/nftables.conf:134:2-44:
>   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
>   Could not process rule: File exists
>                  xx.xxx.xxx.x/23,
>                  ^^^^^^^^^^^^^^^
> 

Resolved by updating userspace.

I can reproduce this error on non-production machine and found this
error is resolved by re-bulding updated nftables, libmnl and libnftnl:

With these versions nft rules now load without error:

 - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
 - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
 - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc

All were compiled on machine running 6.19.4.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Greg KH]

On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
> On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> > On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > > Lo!
> > > 
> > 
> > Repeating the nft error message here for simplicity:
> > 
> >  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
> >   ...
> >   In file included from /etc/nftables.conf:134:2-44:
> >   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
> >   Could not process rule: File exists
> >                  xx.xxx.xxx.x/23,
> >                  ^^^^^^^^^^^^^^^
> > 
> 
> Resolved by updating userspace.
> 
> I can reproduce this error on non-production machine and found this
> error is resolved by re-bulding updated nftables, libmnl and libnftnl:
> 
> With these versions nft rules now load without error:
> 
>  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
>  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
>  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
> 
> All were compiled on machine running 6.19.4.

Odd, that shouldn't be an issue, as why would the kernel version you
build this on matter?

What about trying commit f175b46d9134 ("netfilter: nf_tables: add
.abort_skip_removal flag for set types")?

thanks,

greg k-h

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Genes Lists]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On Fri, 2026-02-27 at 05:17 -0800, Greg KH wrote:
> On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
> > On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> > > On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > > > Lo!
> > > > 
> > > 
> > > Repeating the nft error message here for simplicity:
> > > 
> > >  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
> > >   ...
> > >   In file included from /etc/nftables.conf:134:2-44:
> > >   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
> > >   Could not process rule: File exists
> > >                  xx.xxx.xxx.x/23,
> > >                  ^^^^^^^^^^^^^^^
> > > 
> > 
> > Resolved by updating userspace.
> > 
> > I can reproduce this error on non-production machine and found this
> > error is resolved by re-bulding updated nftables, libmnl and
> > libnftnl:
> > 
> > With these versions nft rules now load without error:
> > 
> >  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
> >  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
> >  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
> > 
> > All were compiled on machine running 6.19.4.
> 
> Odd, that shouldn't be an issue, as why would the kernel version you
> build this on matter?
> 
> What about trying commit f175b46d9134 ("netfilter: nf_tables: add
> .abort_skip_removal flag for set types")?
> 
> thanks,
> 
> greg k-h

- all were rebuilt from git head 
  Have not had time to explore what specific change(s)
  triggered the issue yet.

- commit f175b46d9134
  I can reproduce on non-production machine - will check this and
report back.

gene


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] 6.19.4 stable netfilter / nftables -> resolved

[Genes Lists]

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

On Fri, 2026-02-27 at 09:13 +0100, Florian Westphal wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> 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@moonlit-rail.com/
> 
> 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@netfilter.org>
    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@moonlit-rail.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Jindrich Makovicka]

On Fri, 2026-02-27 at 08:39 -0500, Genes Lists wrote:
> On Fri, 2026-02-27 at 05:17 -0800, Greg KH wrote:
> > On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
> > > On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> > > > On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > > > > Lo!
> > > > > 
> > > > 
> > > > Repeating the nft error message here for simplicity:
> > > > 
> > > >  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
> > > >   ...
> > > >   In file included from /etc/nftables.conf:134:2-44:
> > > >   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
> > > >   Could not process rule: File exists
> > > >                  xx.xxx.xxx.x/23,
> > > >                  ^^^^^^^^^^^^^^^
> > > > 
> > > 
> > > Resolved by updating userspace.
> > > 
> > > I can reproduce this error on non-production machine and found
> > > this
> > > error is resolved by re-bulding updated nftables, libmnl and
> > > libnftnl:
> > > 
> > > With these versions nft rules now load without error:
> > > 
> > >  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
> > >  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
> > >  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
> > > 
> > > All were compiled on machine running 6.19.4.
> > 
> > Odd, that shouldn't be an issue, as why would the kernel version
> > you
> > build this on matter?
> > 
> > What about trying commit f175b46d9134 ("netfilter: nf_tables: add
> > .abort_skip_removal flag for set types")?
> > 
> > thanks,
> > 
> > greg k-h
> 
> - all were rebuilt from git head 
>   Have not had time to explore what specific change(s)
>   triggered the issue yet.
> 
> - commit f175b46d9134
>   I can reproduce on non-production machine - will check this and
> report back.

I had a similar problem, solved by reverting the commit below. It fails
only with a longer set. My wild guess is a closed interval with start
address at the  end of a chunk and end address at the beginning of the
next one gets misidentified as an open interval.

commit 12b1681793e9b7552495290785a3570c539f409d
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Feb 6 13:33:46 2026 +0100

    netfilter: nft_set_rbtree: validate open interval overlap

Example set definition is here:

https://bugzilla.kernel.org/show_bug.cgi?id=221158

Using nft from Debian unstable

$ ./nft --version
nftables v1.1.6 (Commodore Bullmoose #7)

Regards,
-- 
Jindrich Makovicka

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Thorsten Leemhuis]

On 3/3/26 08:00, Jindrich Makovicka wrote:
> On Fri, 2026-02-27 at 08:39 -0500, Genes Lists wrote:
>> On Fri, 2026-02-27 at 05:17 -0800, Greg KH wrote:
>>> On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
>>>> On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
>>>>> On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
>>>>>> Lo!
>>>>>>
>>>>>
>>>>> Repeating the nft error message here for simplicity:
>>>>>
>>>>>  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
>>>>>   ...
>>>>>   In file included from /etc/nftables.conf:134:2-44:
>>>>>   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
>>>>>   Could not process rule: File exists
>>>>>                  xx.xxx.xxx.x/23,
>>>>>                  ^^^^^^^^^^^^^^^
>>>>>
>>>>
>>>> Resolved by updating userspace.
>>>>
>>>> I can reproduce this error on non-production machine and found
>>>> this
>>>> error is resolved by re-bulding updated nftables, libmnl and
>>>> libnftnl:
>>>>
>>>> With these versions nft rules now load without error:
>>>>
>>>>  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
>>>>  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
>>>>  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
>>>>
>>>> All were compiled on machine running 6.19.4.
>>>
>>> Odd, that shouldn't be an issue, as why would the kernel version
>>> you
>>> build this on matter?
>>>
>>> What about trying commit f175b46d9134 ("netfilter: nf_tables: add
>>> .abort_skip_removal flag for set types")?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> - all were rebuilt from git head 
>>   Have not had time to explore what specific change(s)
>>   triggered the issue yet.
>>
>> - commit f175b46d9134
>>   I can reproduce on non-production machine - will check this and
>> report back.
> 
> I had a similar problem, solved by reverting the commit below. It fails
> only with a longer set. My wild guess is a closed interval with start
> address at the  end of a chunk and end address at the beginning of the
> next one gets misidentified as an open interval.
> 
> commit 12b1681793e9b7552495290785a3570c539f409d
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date:   Fri Feb 6 13:33:46 2026 +0100
> 
>     netfilter: nft_set_rbtree: validate open interval overlap
> 
> Example set definition is here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=221158

Does that problem happen with 7.0-rc2 as well? This is important to know
to determine if this is a general problem or a backporting problem.

Ciao, Thorsten

> Using nft from Debian unstable
> 
> $ ./nft --version
> nftables v1.1.6 (Commodore Bullmoose #7)
> 
> Regards,

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Jindrich Makovicka]

On Tue, 2026-03-03 at 08:31 +0100, Thorsten Leemhuis wrote:
> On 3/3/26 08:00, Jindrich Makovicka wrote:
> > On Fri, 2026-02-27 at 08:39 -0500, Genes Lists wrote:
> > > On Fri, 2026-02-27 at 05:17 -0800, Greg KH wrote:
> > > > On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
> > > > > On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> > > > > > On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > > > > > > Lo!
> > > > > > > 
> > > > > > 
> > > > > > Repeating the nft error message here for simplicity:
> > > > > > 
> > > > > >  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
> > > > > >   ...
> > > > > >   In file included from /etc/nftables.conf:134:2-44:
> > > > > >   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
> > > > > >   Could not process rule: File exists
> > > > > >                  xx.xxx.xxx.x/23,
> > > > > >                  ^^^^^^^^^^^^^^^
> > > > > > 
> > > > > 
> > > > > Resolved by updating userspace.
> > > > > 
> > > > > I can reproduce this error on non-production machine and
> > > > > found
> > > > > this
> > > > > error is resolved by re-bulding updated nftables, libmnl and
> > > > > libnftnl:
> > > > > 
> > > > > With these versions nft rules now load without error:
> > > > > 
> > > > >  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
> > > > >  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
> > > > >  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
> > > > > 
> > > > > All were compiled on machine running 6.19.4.
> > > > 
> > > > Odd, that shouldn't be an issue, as why would the kernel
> > > > version
> > > > you
> > > > build this on matter?
> > > > 
> > > > What about trying commit f175b46d9134 ("netfilter: nf_tables:
> > > > add
> > > > .abort_skip_removal flag for set types")?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > - all were rebuilt from git head 
> > >   Have not had time to explore what specific change(s)
> > >   triggered the issue yet.
> > > 
> > > - commit f175b46d9134
> > >   I can reproduce on non-production machine - will check this and
> > > report back.
> > 
> > I had a similar problem, solved by reverting the commit below. It
> > fails
> > only with a longer set. My wild guess is a closed interval with
> > start
> > address at the  end of a chunk and end address at the beginning of
> > the
> > next one gets misidentified as an open interval.
> > 
> > commit 12b1681793e9b7552495290785a3570c539f409d
> > Author: Pablo Neira Ayuso <pablo@netfilter.org>
> > Date:   Fri Feb 6 13:33:46 2026 +0100
> > 
> >     netfilter: nft_set_rbtree: validate open interval overlap
> > 
> > Example set definition is here:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=221158
> 
> Does that problem happen with 7.0-rc2 as well? This is important to
> know
> to determine if this is a general problem or a backporting problem.
> 

Yes, the same problem shows up with 7.0-rc2. I updated the bugzilla
attachment to reproduce the bug just by feeding it to nft,

# uname -a
Linux holly 7.0.0-rc2 #25 SMP PREEMPT_DYNAMIC Tue Mar  3 18:17:21 CET
2026 x86_64 GNU/Linux
# nft -f test-full.nft
test-full.nft:1643:1-25: Error: Could not process rule: File exists
12.14.179.24-12.14.179.31,
^^^^^^^^^^^^^^^^^^^^^^^^^

Regards,
-- 
Jindrich Makovicka

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Florian Westphal]

Jindrich Makovicka <makovick@gmail.com> wrote:
> > > commit 12b1681793e9b7552495290785a3570c539f409d
> > > Author: Pablo Neira Ayuso <pablo@netfilter.org>
> > > Date:   Fri Feb 6 13:33:46 2026 +0100
> > > 
> > >     netfilter: nft_set_rbtree: validate open interval overlap
> > > 
> > > Example set definition is here:
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=221158
> > 
> > Does that problem happen with 7.0-rc2 as well? This is important to
> > know
> > to determine if this is a general problem or a backporting problem.
> > 
> 
> Yes, the same problem shows up with 7.0-rc2. I updated the bugzilla
> attachment to reproduce the bug just by feeding it to nft,
> 
> # uname -a
> Linux holly 7.0.0-rc2 #25 SMP PREEMPT_DYNAMIC Tue Mar  3 18:17:21 CET
> 2026 x86_64 GNU/Linux
> # nft -f test-full.nft
> test-full.nft:1643:1-25: Error: Could not process rule: File exists
> 12.14.179.24-12.14.179.31,
> ^^^^^^^^^^^^^^^^^^^^^^^^^

Pablo, it looks like the is a discrepancy between the comment and the
code.  Comment talks about 'open interval', but it checks that some
start interval was found instead of checking that the OPEN_INTERVAL
bit is raised:

diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -556,7 +556,8 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
        /* - start element overlaps an open interval but end element is new:
         *   partial overlap, reported as -ENOEMPTY.
         */
-       if (!rbe_ge && priv->start_rbe_cookie && nft_rbtree_interval_end(new))
+       if (!rbe_ge && priv->start_rbe_cookie & NFT_RBTREE_OPEN_INTERVAL &&
+           nft_rbtree_interval_end(new))
                return -ENOTEMPTY;


Does that look correct to you?

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Pablo Neira Ayuso]

On Tue, Mar 03, 2026 at 08:00:54AM +0100, Jindrich Makovicka wrote:
> On Fri, 2026-02-27 at 08:39 -0500, Genes Lists wrote:
> > On Fri, 2026-02-27 at 05:17 -0800, Greg KH wrote:
> > > On Fri, Feb 27, 2026 at 08:12:59AM -0500, Genes Lists wrote:
> > > > On Fri, 2026-02-27 at 07:23 -0500, Genes Lists wrote:
> > > > > On Fri, 2026-02-27 at 09:00 +0100, Thorsten Leemhuis wrote:
> > > > > > Lo!
> > > > > > 
> > > > > 
> > > > > Repeating the nft error message here for simplicity:
> > > > > 
> > > > >  Linux version 7.0.0-rc1-custom-1-00124-g3f4a08e64442 ...
> > > > >   ...
> > > > >   In file included from /etc/nftables.conf:134:2-44:
> > > > >   ./etc/nftables.d/set_filter.conf:1746:7-21: Error:
> > > > >   Could not process rule: File exists
> > > > >                  xx.xxx.xxx.x/23,
> > > > >                  ^^^^^^^^^^^^^^^
> > > > > 
> > > > 
> > > > Resolved by updating userspace.
> > > > 
> > > > I can reproduce this error on non-production machine and found
> > > > this
> > > > error is resolved by re-bulding updated nftables, libmnl and
> > > > libnftnl:
> > > > 
> > > > With these versions nft rules now load without error:
> > > > 
> > > >  - nftables commit de904e22faa2e450d0d4802e1d9bc22013044f93
> > > >  - libmnl   commit 54dea548d796653534645c6e3c8577eaf7d77411
> > > >  - libnftnl commit 5c5a8385dc974ea7887119963022ae988e2a16cc
> > > > 
> > > > All were compiled on machine running 6.19.4.
> > > 
> > > Odd, that shouldn't be an issue, as why would the kernel version
> > > you
> > > build this on matter?
> > > 
> > > What about trying commit f175b46d9134 ("netfilter: nf_tables: add
> > > .abort_skip_removal flag for set types")?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > - all were rebuilt from git head 
> >   Have not had time to explore what specific change(s)
> >   triggered the issue yet.
> > 
> > - commit f175b46d9134
> >   I can reproduce on non-production machine - will check this and
> > report back.
> 
> I had a similar problem, solved by reverting the commit below. It fails
> only with a longer set. My wild guess is a closed interval with start
> address at the  end of a chunk and end address at the beginning of the
> next one gets misidentified as an open interval.

Yes, but such behaviour already breaks the create element, see my
userspace fix. See:

commit e83e32c8d1cd228d751fb92b756306c6eb6c0759
Author: Pablo Neira Ayuso <pablo@netfilter.org>
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.
    
    The code that tracks the start and end elements of the interval can add
    the same element twice to the batch. This works with the add element
    command, since it ignores EEXIST error, but it breaks the the create
    element command.
    
    Update this codepath to ensure both sides of the interval fit into the
    netlink message, otherwise, trim the netlink message to remove them.
    So the next netlink message includes the elements that represent the
    interval that could not fit.

> commit 12b1681793e9b7552495290785a3570c539f409d
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date:   Fri Feb 6 13:33:46 2026 +0100
> 
>     netfilter: nft_set_rbtree: validate open interval overlap

I guess you are testing with 7.0-rc, correct?

A new userspace release with this fix is required.

> Example set definition is here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=221158
> 
> Using nft from Debian unstable
> 
> $ ./nft --version
> nftables v1.1.6 (Commodore Bullmoose #7)

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Thorsten Leemhuis]

On 3/3/26 23:03, Pablo Neira Ayuso wrote:
 
> A new userspace release with this fix is required.

But a new user space should never be required for a new kernel. Find a
few quotes from Linus on this below. And I noticed other people ran
into this, too, so it's not a corner case:
https://lore.kernel.org/all/aaeIDJigEVkDfrRg@chamomile/

So should this be reverted everywhere where this was applied? Or is
there some way to do what the commit wanted to do without breaking
userspace?

"""
* From `2018-08-03 <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_::

    And dammit, we upgrade the kernel ALL THE TIME without upgrading any
    other programs at all. It is absolutely required, because flag-days
    and dependencies are horribly bad.

    And it is also required simply because I as a kernel developer do not
    upgrade random other tools that I don't even care about as I develop the
    kernel, and I want any of my users to feel safe doing the same time.

* From `2017-10-26(3) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_::

    But if something actually breaks, then the change must get fixed or
    reverted. And it gets fixed in the *kernel*. Not by saying "well, fix your
    user space then". It was a kernel change that exposed the problem, it needs
    to be the kernel that corrects for it, because we have a "upgrade in place"
    model. We don't have a "upgrade with new user space".

    And I seriously will refuse to take code from people who do not understand
    and honor this very simple rule.

    This rule is also not going to change.

    And yes, I realize that the kernel is "special" in this respect. I'm proud
    of it.

* From `2017-10-26(4) <https://lore.kernel.org/all/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_::

    If you break existing user space setups THAT IS A REGRESSION.

    It's not ok to say "but we'll fix the user space setup".

    Really. NOT OK.
"""
 
Ciao, THorsten

Re: [REGRESSION] 6.19.4 stable netfilter / nftables [resolved]

[Pablo Neira Ayuso]

On Wed, Mar 04, 2026 at 06:50:32AM +0100, Thorsten Leemhuis wrote:
> On 3/3/26 23:03, Pablo Neira Ayuso wrote:
>  
> > A new userspace release with this fix is required.
> 
> But a new user space should never be required for a new kernel. Find a
> few quotes from Linus on this below. And I noticed other people ran
> into this, too, so it's not a corner case:
> https://lore.kernel.org/all/aaeIDJigEVkDfrRg@chamomile/
> 
> So should this be reverted everywhere where this was applied? Or is
> there some way to do what the commit wanted to do without breaking
> userspace?

Thanks for explaining.

I kindly requested to revert in -stable:

  netfilter: nft_set_rbtree: validate open interval overlap

which amplifies the userspace bug.