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 nftctsetzoneeval() (nfcttmplalloc -> kzalloc, tuple is all zero, nfctl3num(ct) == 0). The next expression then calls nftctgeteval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFTREG3215 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 nftctgetfasteval(), mirroring the check nftctseteval() already has. Additionally, bound the address copy in NFTCTSRC / NFTCTDST by priv->len instead of by nfctl3num(ct): nfctgettuple() zeroes the tuple before pkttotuple() 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.