PT-2026-52362 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53267
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux