Backport request for fix currently being applied to older Ubuntu releases: Ref: https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/2142552 From that bug: [ Impact ] * When one uses newer & older nftables on the same host (for example from new and old containers) the old nftables can start crashing with segfaults. * This is very pronounced when deploying kubernetes and for example deploying istio or calico with containers that have newer nftables (newer than 1.1.1) and subsequently older nftables (on the host or another container) are used. https://git.netfilter.org/nftables/commit/?id=be737a1986bfee0ddea4bee7863dca0123a2bcbc Whenever a new version adds udata support to an expression, then old versions of nft will crash when trying to list such a ruleset generated by a more recent version of nftables. Fix this by falling back to 'type' format. Fixes: 6e48df5329ea ('src: add "typeof" build/parse/print support') Signed-off-by: Florian Westphal <email address hidden> Reviewed-by: Pablo Neira Ayuso <email address hidden> Also see: - https://github.com/istio/istio/issues/58492 Reproducible: Always Steps to Reproduce: 1. Add a set using a version of nftables > 1.1.3 (eg in a container in the host network namespace # podman run --rm -it --privileged --network host quay.io/fedora/fedora:43 /bin/bash {container}# dnf install -y nftables {container}# nft add table test {container}# nft 'add set test dummy { type ipv4_addr; }' 2. Attempt to list the ruleset on the F42 host: # nft list ruleset Actual Results: Segmentation fault (core dumped) Expected Results: List of current ruleset Additional Information: Newer versions of nftables add sets/chains that have udata added, and nftables 1.1.1 on F42 currently lacks the patch to correctly handle the udata, and crashes. The fix is linked above, but the patch is as simple as: --- a/src/netlink.c 2024-09-26 07:17:41.004675285 -0700 +++ b/src/netlink.c 2026-02-05 11:39:31.654321471 -0800 @@ -913,7 +913,7 @@ etype = nftnl_udata_get_u32(ud[NFTNL_UDATA_SET_TYPEOF_EXPR]); ops = expr_ops_by_type_u32(etype); - if (!ops) + if (!ops || !ops->parse_udata) return NULL; expr = ops->parse_udata(ud[NFTNL_UDATA_SET_TYPEOF_DATA]); Without the patch, any container with a reasonably new version of nftables (including F43+) in the host namespace can lead to nftables being unavailable on the host. NOTE: this bug probably affects F41 as well... The bug is fixed in F43, but F43+ will also trigger the problem in F42 or below in the same network namespace.
FEDORA-2026-0a171392b4 (nftables-1.1.1-3.fc42.1) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-0a171392b4
Thanks Phil... forgot that we should future proof 1.1.3 against even newer nft versions too :)
FEDORA-2026-0a171392b4 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-0a171392b4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0a171392b4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Can I please ask if separate issues needs to be opened for Centos Stream and RHEL products? This issue originated from redhat engineers working on istio, and thus I believe OpenShift products, Centos, and RHEL are also affected.
Hi Scott, (In reply to Scott Shambarger from comment #2) > Thanks Phil... forgot that we should future proof 1.1.3 against even newer > nft versions too :) The only real "future proof" is a song by Massive Attack. ;) While defensive coding surely helps preventing crashes (real ones, not the overly frequent call to BUG() in unexpected situations), forward compatibility is a utopian goal with nftables due to how data is exchanged between kernel and user space and (at least upstream's) need to implement new features. Best we can do is detect the situation. Upstream's current approach for this is to attach the creating nftables' version to new tables and warn the user if parsing a table which has a newer version number than the current one.
(In reply to Dimitri John Ledkov from comment #4) > Can I please ask if separate issues needs to be opened for Centos Stream and > RHEL products? > > This issue originated from redhat engineers working on istio, and thus I > believe OpenShift products, Centos, and RHEL are also affected. Already done: https://issues.redhat.com/browse/RHEL-152438