Hi,
On 29/12/24 15:30, lilydjwg wrote:
I have an IPv4 set with timeout 2d, but update its elements to 4d when
a rule matches. It was fine until kernel is updated to 6.12.6 or 6.12.7.
E.g. the following snippet gives an error when importing:
table inet blocker {
set spam_ips {
type ipv4_addr
size 65535
flags dynamic,timeout
timeout 2d
elements = { 1.2.3.4 expires 3d }
}
}
a.nft:7:16-22: Error: Could not process rule: Numerical result out of range
elements = { 1.2.3.4 expires 3d }
^^^^^^^
Note: I looked through the commits and this looks like a relevant commit:
commit c0f38a8c60174368aed1d0f9965d733195f15033
Author: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Date: Tue Sep 3 01:06:58 2024 +0200
netfilter: nf_tables: reject expiration higher than timeout
Report ERANGE to userspace if user specifies an expiration larger than
the timeout.
Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger
than 23 days")
Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index da75bc1de466..6c0c6f8a08a8 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -6930,6 +6930,9 @@ static int nft_add_set_elem(struct nft_ctx *ctx,
struct nft_set *set,
&expiration);
if (err)
return err;
+
+ if (expiration > timeout)
+ return -ERANGE;
}
if (nla[NFTA_SET_ELEM_EXPR]) {
Thanks,
Harshit
kernel 6.10.6 worked just fine. nftables cli v1.1.1.
Despite I can't import the set, existing elements can still be updated
to timeout more that 2d.
A new bug? Or a new limitation?
