Re: [PATCH v2] netfilter: nft_ct: reject ambiguous conntrack expressions in inet tables

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Sep 02, 2025 at 11:54:33PM +0200, Nikolaos Gkarlis wrote:
> The kernel allows netlink messages that use the legacy NFT_CT_SRC and
> NFT_CT_DST keys in inet tables without an accompanying nft_meta
> expression specifying NFT_META_NFPROTO. This results in ambiguous
> conntrack expressions that cannot be reliably evaluated during packet
> processing.
> 
> When that happens, 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 use
> NFT_CT_SRC_IP(6) and NFT_CT_DST_IP(6) keys when NFT_META_NFPROTO is
> not defined.
> 
> Fix by adding a pointer to the parent nft_rule in nft_expr, allowing
> iteration over preceding expressions to ensure that an nft_meta with
> NFT_META_NFPROTO has been defined.

I think it is easier to work around this from userspace by translating
NFT_CT_SRC to NFT_CT_SRC_{IPV4,IPV6} by peeking the datatype at the
rhs of the relational.

NFT_CT_{SRC,DST} only works with relational expression, they are
broken with sets, that's why NFT_CT_SRC_{IPV4,IPV6} was introduced
(which works with both relational expressions and sets).

IIRC, I removed documentation for this syntax time ago with the
expectation, it seems someone found it and it is buggy with
NFPROTO_INET as you describe.