The kernel accepts netlink messages using the legacy NFT_CT_SRC, NFT_CT_DST keys in inet tables, creating ambiguous conntrack expressions that cannot be properly evaluated during packet processing. When NFPROTO_INET is used with NFT_CT_SRC, NFT_CT_DST the register size calculation defaults to IPv6 (16 bytes) regardless of the actual packet family. This causes two issues: 1. For IPv4 packets, only 4 bytes contain valid address data while 12 bytes contain uninitialized memory during comparison. 2. nft userspace cannot properly display these rules ([invalid type]). The bug is not reproducible through standard nft commands, which properly use NFT_CT_SRC_IP(6), NFT_CT_DST_IP(6) keys instead. Fix by rejecting such expressions with EAFNOSUPPORT when used in inet tables. Signed-off-by: Nikolaos Gkarlis <nickgarlis@xxxxxxxxx> --- As an example, packets from 192.0.2.1 (0xc0000201) would also match rules filtering on c000:201:: (0xc0000201000000000000000000000000), which is likely unintended. To my knowledge, the keys NFT_CT_SRC and NFT_CT_DST were never officially used by nft userspace, so I assume rejecting them should be safe. I have tested this change and it appears to work as expected. net/netfilter/nft_ct.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c index d526e69a2..23ce90975 100644 --- a/net/netfilter/nft_ct.c +++ b/net/netfilter/nft_ct.c @@ -439,7 +439,6 @@ static int nft_ct_get_init(const struct nft_ctx *ctx, src.u3.ip); break; case NFPROTO_IPV6: - case NFPROTO_INET: len = sizeof_field(struct nf_conntrack_tuple, src.u3.ip6); break; -- 2.34.1
