Arno DUBOIS <arno.du@xxxxxxxxx> wrote:
> I've been trying to switch my Kube CNIs to use nftables directly.
> However, I get coredumps everywhere in my system.
>
> I successfully extracted the commands sent to the tool from the CNI:
> ```
> add table inet cni_plugins_masquerade
> add chain inet cni_plugins_masquerade masq_checks
> add chain inet cni_plugins_masquerade postrouting { type nat hook
> postrouting priority 100 ; }
> flush chain inet cni_plugins_masquerade postrouting
>
> add rule inet cni_plugins_masquerade postrouting ip daddr ==
> 224.0.0.0/24 return
> add rule inet cni_plugins_masquerade postrouting ip6 daddr == ff00::/8 return
> add rule inet cni_plugins_masquerade postrouting goto masq_checks
> add rule inet cni_plugins_masquerade masq_checks ip saddr ==
> 10.244.0.198 ip daddr != 10.244.0.0/24 masquerade
> ```
> I definitely am not an nftables professional, but they seem correct to me.
Yes.
> When running that, at the minute I try to add the rules (if I run the
> commands one by one) I receive a SEGFAULT (after some processing
> time).
> I did do a quick run with GDB if that can help:
Thanks, this helps indeed.
> (gdb) run add rule inet cni_plugins_masquerade postrouting ip daddr
> 192.168.1.1 return
> Starting program: /usr/bin/nft add rule inet cni_plugins_masquerade
> postrouting ip daddr 192.168.1.1 return
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0 0x0000000000000000 in ?? ()
> #1 0x00007ffff7ef3740 in set_make_key (attr=0x5555556017e6) at
> src/netlink.c:919
This is crashing when decoding the set/map key of the existing ruleset.
I think its the bug fixed with
be737a1986bf ("src: netlink: fix crash when ops doesn't support udata")
... which went into nftables 1.1.4 release.
