nft segfault on debian trixie

[jsmouret]

It looks like there is a version incompatibility with nftables on Debian Trixie.

Expected Behavior

No errors

Current Behavior

Reconciliation loops with errors:

$ kubectl logs -n calico-system calico-node-htqgt

2026-01-30 21:11:15.382 [WARNING][47] felix/table.go 587: Failed to load maps state error=error listing nftables maps: failed to run nft: signal: segmentation fault ipVersion=0x4 table="calico"
2026-01-30 21:11:15.408 [WARNING][47] felix/table.go 587: Failed to load maps state error=error listing nftables maps: failed to run nft: signal: segmentation fault ipVersion=0x6 table="calico"
2026-01-30 21:11:35.014 [WARNING][47] felix/table.go 587: Failed to load maps state error=error listing nftables maps: failed to run nft: signal: segmentation fault ipVersion=0x6 table="calico"
2026-01-30 21:11:35.015 [WARNING][47] felix/table.go 587: Failed to load maps state error=error listing nftables maps: failed to run nft: signal: segmentation fault ipVersion=0x4 table="calico"
2026-01-30 21:11:35.072 [INFO][47] felix/summary.go 100: Summarising 6 dataplane reconciliation loops over 1m1s: avg=118ms longest=197ms (resync-calico-v4,resync-calico-v6)

which matches errors on the host:

$ dmesg
[1453664.183356] nft[2663996]: segfault at 0 ip 0000000000000000 sp 00007ffc3cc5fab8 error 14 likely on CPU 1 (core 1, socket 0)
[1453664.187459] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[1453684.179986] nft[2664094]: segfault at 0 ip 0000000000000000 sp 00007ffc329f4958 error 14 likely on CPU 0 (core 0, socket 0)
[1453684.184930] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[1453684.199519] nft[2664097]: segfault at 0 ip 0000000000000000 sp 00007ffd00953388 error 14 likely on CPU 1 (core 1, socket 0)
[1453684.203321] Code: Unable to access opcode bytes at 0xffffffffffffffd6.

Possible Solution

Maybe upgrade calico image with a fresher nftables package?

host: nftables v1.1.3 (Commodore Bullmoose #4)
calico node: nftables v1.0.4 (Lester Gooch #3)

Steps to Reproduce (for bugs)

in a calico pod:

$ nft list ruleset
Segmentation fault

Context

The issue was found because core dumps filled up the host drive.
The workaround was to disable core dumps in containerd:
in /lib/systemd/system/containerd.service, add LimitCORE=0.

Your Environment

• Calico version: v3.31.3

• Calico dataplane: iptables/nft backend

• Orchestrator version: kubeadm v1.34.3

• Operating System and version: Linux 6.12.63+deb13-amd64 / Debian 13 (Trixie)

• Felix config:

spec:
  bpfEnabled: false
  bpfLogLevel: ""
  floatingIPs: Disabled
  healthPort: 9099
  ipipEnabled: false
  iptablesBackend: NFT
  logSeverityScreen: Info
  nftablesMode: Disabled
  reportingInterval: 0s
  vxlanPort: 4789
  vxlanVNI: 4096
  wireguardEnabled: true
  wireguardEnabledV6: true
  wireguardListeningPort: 1194
  wireguardListeningPortV6: 1195

Thanks for your help :)

[jsmouret]

maybe similar: istio/istio#58492

[jsmouret]

workaround is to downgrade nftables to 1.1.1 on the host

wget https://snapshot.debian.org/archive/debian/20241004T143558Z/pool/main/n/nftables/nftables_1.1.1-1_amd64.deb
wget https://snapshot.debian.org/archive/debian/20241004T143558Z/pool/main/n/nftables/libnftables1_1.1.1-1_amd64.deb
apt install ./nftables_1.1.1-1_amd64.deb ./libnftables1_1.1.1-1_amd64.deb
apt-mark hold nftables

and restart your ingress daemons

[sshambar]

I hit this on a Fedora 43 host (nftables 1.1.3) which was adding a nftables set, and Calico's nft started crashing.

A fix for the older nft versions appears to be:
https://git.netfilter.org/nftables/commit/?id=be737a1986bfee0ddea4bee7863dca0123a2bcbc

I built nftables 1.1.1 with the above patch and I was able to run nft list sets and nft list ruleset without it crashing...

It might be prudent to use a patched 1.1.1 build to:
a) not introduce udata sets on the host (thereby breaking other older nft builds)
b) support other containers potentially adding sets with udata (ie newer nftables in the same network namespace)

[sshambar]

As a followup, I reported the bug against kube-proxy as well, and they are proposing a workaround of using nft list table xxx on only their own tables in json mode, and retrieving the nft sets without ever parsing sets from other tables that crash nft. If calico could do something similar, then a patched nft wouldn't be needed.

[tomastigera]

yeah, we will need to update the images