CVE-2026-53267

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_ct: bail out on template ct in get eval

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

A rule like the one below is enough to trigger the bug:

table ip t {

chain pre {

type filter hook prerouting priority raw;

ct zone set 1

ct original saddr 1.2.3.4 accept

}

}

The first expression attaches a per-cpu template ct via

nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all

zero, nf_ct_l3num(ct) == 0). The next expression then calls

nft_ct_get_eval() on the same skb, treats the template as a real ct

and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this

overflows past struct nft_regs on the kernel stack; with smaller

dreg values it silently clobbers adjacent registers.

Reject template ct at the eval entry and in nft_ct_get_fast_eval(),

mirroring the check nft_ct_set_eval() already has. Additionally,

bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len

instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple

before pkt_to_tuple() fills in only the protocol-relevant leading

bytes, so the trailing bytes of tuple->{src,dst}.u3.all are

well-defined zero. priv->len is validated at rule load, so the

copy size is now bounded by the destination register rather than

by an untrusted field on the conntrack.

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