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@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.
    
    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@xxxxxxxxxxxxx>
> 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)