nftables >= 0.9.8: atomic update (nft -f ...) of a set not possible any more

["etkaar" <lists.netfilter.org@xxxxxxx>]

Dear colleagues,

given is following perfectly working ruleset (nft list ruleset), which drops almost all of the IPv4 traffic, but grants access to port 22 (SSH) for two IPv4 addresses provided by the set named 'whitelist_ipv4_tcp':

+++
table inet filter {
	set whitelist_ipv4_tcp {
		type inet_service . ipv4_addr
		flags interval
		elements = { 22 . 111.222.333.444,
			     22 . 555.666.777.888 }
	}

	set whitelist_ipv4_udp {
		type inet_service . ipv4_addr
		flags interval
	}

	set blacklist_ipv4 {
		type ipv4_addr
		flags interval
	}

	chain default_input {
		type filter hook input priority filter + 1; policy drop;
		ip saddr @blacklist_ipv4 drop
		ct state established,related accept
		ct state invalid drop
		iifname "lo" accept
		ip protocol icmp icmp type { echo-reply, destination-unreachable, echo-request, router-advertisement, router-solicitation, time-exceeded, parameter-problem } accept
		meta nfproto ipv4 tcp dport . ip saddr @whitelist_ipv4_tcp accept
		meta nfproto ipv4 udp dport . ip saddr @whitelist_ipv4_udp accept
	}

	chain default_forward {
		type filter hook forward priority filter; policy drop;
	}

	chain default_output {
		type filter hook output priority filter; policy accept;
		oifname "lo" accept
	}
}

+++

Now comes the strange thing: In case the ruleset is atomically updated using following file (nft -f ...) the output of 'nft list ruleset' does not change at all (which is expected!), but now the IPv4 addresses do not any more have access:

+++
#!/usr/sbin/nft -f
flush set inet filter whitelist_ipv4_tcp
flush set inet filter whitelist_ipv4_udp
table inet filter {
	set whitelist_ipv4_tcp {
		type inet_service . ipv4_addr; flags interval;
		elements = {
			22 . 111.222.333.444/32,
			22 . 555.666.777.888/32,
		}
	}
	set whitelist_ipv4_udp {
		type inet_service . ipv4_addr; flags interval;
	}
}

+++

I have double-checked that in the logs:

+++
nft dropped: [...] SRC=111.222.333.444 DST=194.48.XXX.XX [...] DPT=22 [...]
+++

This problem is not present in Debian 10 (Buster) which uses nftables 0.9.0. But it is present in Debian 11 (Bullseye) which uses nftables 0.9.8. Because I even got a segmentation fault here I cannot reproduce yet, I tried it with nftables 1.0.1 - but still no success.

I don't understand how the 'nft list ruleset' output can be identical after using 'nft -f ...'. In any case, the IPv4 addresses are part of the whitelist set and are unexpectedly blocked.

Kind Regards,
etkaar