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

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

I noticed this issue while looking at a historic syzbot report [1].

syzbot forces dreg[19] to be used as the storage for the ipv4 address,
together with a raw priority chain, which makes nf_ct_l3num(ct) be 0
so that 16 bytes get copied into dreg[19]. Even when the dreg is not
[19], the same larger-than-expected copy can clobber other regs.

I am not sure whether there are other paths; here we add a check to
fix the deprecated NFT_CT_SRC and NFT_CT_DST branches.

[1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c

Fixes: 45d9bcda21f4 ("netfilter: nf_tables: validate len in nft_validate_data_load()")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/netfilter/nft_ct.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
index fa2cc556331c..813467de1479 100644
--- a/net/netfilter/nft_ct.c
+++ b/net/netfilter/nft_ct.c
@@ -61,6 +61,7 @@ static void nft_ct_get_eval(const struct nft_expr *expr,
 	const struct nf_conntrack_tuple *tuple;
 	const struct nf_conntrack_helper *helper;
 	unsigned int state;
+	u8 addr_len;
 
 	ct = nf_ct_get(pkt->skb, &ctinfo);
 
@@ -178,14 +179,17 @@ static void nft_ct_get_eval(const struct nft_expr *expr,
 	}
 
 	tuple = &ct->tuplehash[priv->dir].tuple;
+	addr_len = nf_ct_l3num(ct) == NFPROTO_IPV4 ? 4 : 16;
 	switch (priv->key) {
 	case NFT_CT_SRC:
-		memcpy(dest, tuple->src.u3.all,
-		       nf_ct_l3num(ct) == NFPROTO_IPV4 ? 4 : 16);
+		if (priv->len != addr_len)
+			goto err;
+		memcpy(dest, tuple->src.u3.all, addr_len);
 		return;
 	case NFT_CT_DST:
-		memcpy(dest, tuple->dst.u3.all,
-		       nf_ct_l3num(ct) == NFPROTO_IPV4 ? 4 : 16);
+		if (priv->len != addr_len)
+			goto err;
+		memcpy(dest, tuple->dst.u3.all, addr_len);
 		return;
 	case NFT_CT_PROTO_SRC:
 		nft_reg_store16(dest, (__force u16)tuple->src.u.all);
-- 
2.43.0