PT-2026-52362 · Linux · Linux
Publicado
2026-06-25
·
Atualizado
2026-06-25
·
CVE-2026-53267
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux