Re: [PATCH nf-next v3] netfilter: nf_tables: add math expression support

[Phil Sutter <phil@nwl.cc>]

On Wed, Feb 04, 2026 at 05:44:14PM +0100, Fernando Fernandez Mancera wrote:
> On 2/4/26 5:07 PM, Phil Sutter wrote:
> > Hi Fernando,
> > 
> > On Wed, Feb 04, 2026 at 04:23:58PM +0100, Fernando Fernandez Mancera wrote:
> >> Historically, users have requested support for increasing and decreasing
> >> TTL value in nftables in order to migrate from iptables.
> >>
> >> Following the nftables spirit of flexible and multipurpose expressions,
> >> this patch introduces "nft_math" expression. This expression allows to
> >> increase and decrease u32, u16 and u8 values stored in the nftables
> >> registers.
> >>
> >> The math expression intends to be flexible enough in case it needs to be
> >> extended in the future, e.g implement bitfields operations. For this
> >> reason, the length of the data is indicated in bits instead of bytes.
> >>
> >> When loading a u8 or u16 payload into a register we don't know if the
> >> value is stored at least significant byte or most significant byte. In
> >> order to handle such cases, introduce a bitmask indicating what is the
> >> target bit and also use it to handle limits to prevent overflow.
> > 
> > This part puzzles me. IMO byteorder conversion is needed for arithmetic
> > on multi-byte values in non-host byte order.
> > 
> > Since nftables only knows host byte order and network byte order, the
> > only case to consider is Little Endian host with NBO data. Registers are
> > filled "from left to right", so (u16)0x1337 and (u32)0xfeedbabe look
> > like this when stored in Network Byte Order in registers:
> > 
> > { 0x13, 0x37, 0x00, 0x00 }
> > { 0xfe, 0xed, 0xba, 0xbe }
> > 
> > Interpreting those buffers as u16/u32 on Little Endian results in values
> > 0x3713 and 0xbebaedfe. Any increment/decrement on those values leads to
> > wrong results.
> > 
> > Maybe there's a hidden secret in 'bit_unit', but even if you calculate
> > the right value to add/subtract from the right byte (0x100 and 0x1000000
> > in our examples), a possible carry-over bumps the wrong byte.
> > 
> 
> Hi!
> 
> This is correct. In the initial implementation [1] I included a 
> NFTA_MATH_BYTEORDER attribute but after discussing with Florian we 
> decided to drop it. Of course, in order to make this work correctly, nft 
> byteorder expression must be used to perform the conversion when needed.
> 
> I believe that nft command line tool can figure out when a byteorder 
> conversion is needed as I noticed this is already done for other 
> expressions.
> 
> My initial idea was to keep the bytecode as smaller as possible but it 
> is true that it makes sense to use the existing byteorder operations.
> 
> Does this make sense or am I missing something?

Ah, got it! So nft_math simply assumes sreg and dreg are in host byte
order and nftables is supposed to add nft_byteorder expressions as
needed. That should do and is indeed easier than dealing with data
byteorder within nft_math itself!

The only odd thing that remains is the combined use of mask and length.
Typically one would either use length and offset or mask alone because
the former two values may be extracted from the latter. Also, why does
nft_math_init() restrict masks to align at start or end of register?

Thanks, Phil