Re: [PATCH nf] netfilter: nft_ct: fix OOB in NFT_CT_SRC/DST eval

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 5/28/26 4:01 PM, Florian Westphal wrote:
> Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>>>>> nf_ct_l3num(ct) == NFPROTO_IPV6 ? 16 : 4);
>>>> As defense-in-depth, IIUC?
>>> Yes, alternatively merge your v1 with the template check. I don't see how
>>> we can ever have nf_ct_l3num(ct) != nft_pf(pkt) outside of the template
>>> bug.
>> I think the template check plus the family check (nf_ct_l3num(ct) !=
>> nft_pf(pkt)) is enough as defense-in-depth.
> Actually, I think we need to fix this to copy priv->len unconditionally.
> Or, alternatively, add a memcpy wrapper that zero-pads the remainder of
> the registers.
>
> https://sashiko.dev/#/patchset/20260528042620.263828-1-jiayuan.chen%40linux.dev
>
> "This is a pre-existing issue, but does copying only addr_len bytes when
> priv->len is larger leave the remainder of the register uninitialized?
> In nft_do_chain(), the register array is allocated on the kernel stack
> without zero-initialization. If priv->len is 16 and addr_len is 4, only
> the first 4 bytes are written."


I just spotted that too.  I think copying priv->len unconditionally
is enough -- tuple->{src,dst} is zeroed in nf_ct_get_tuple() before the
protocol pkt_to_tuple callback fills in only the relevant leading bytes,
so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zeros
and no wrapper is needed.