CVE-2026-53267

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: bail out on template ct in get eval<br /> <br /> I noticed this issue while looking at a historic syzbot report [1].<br /> <br /> A rule like the one below is enough to trigger the bug:<br /> <br /> table ip t {<br /> chain pre {<br /> type filter hook prerouting priority raw;<br /> ct zone set 1<br /> ct original saddr 1.2.3.4 accept<br /> }<br /> }<br /> <br /> The first expression attaches a per-cpu template ct via<br /> nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -&gt; kzalloc, tuple is all<br /> zero, nf_ct_l3num(ct) == 0). The next expression then calls<br /> nft_ct_get_eval() on the same skb, treats the template as a real ct<br /> and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this<br /> overflows past struct nft_regs on the kernel stack; with smaller<br /> dreg values it silently clobbers adjacent registers.<br /> <br /> Reject template ct at the eval entry and in nft_ct_get_fast_eval(),<br /> mirroring the check nft_ct_set_eval() already has. Additionally,<br /> bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv-&gt;len<br /> instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple<br /> before pkt_to_tuple() fills in only the protocol-relevant leading<br /> bytes, so the trailing bytes of tuple-&gt;{src,dst}.u3.all are<br /> well-defined zero. priv-&gt;len is validated at rule load, so the<br /> copy size is now bounded by the destination register rather than<br /> by an untrusted field on the conntrack.<br /> <br /> [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c