netfilter: nft_ct: bail out on template ct in get eval
Summary
| CVE | CVE-2026-53267 |
|---|
| State | PUBLISHED |
|---|
| Assigner | Linux |
|---|
| Source Priority | CVE Program / NVD first with legacy fallback |
|---|
| Published | 2026-06-25 09:16:44 UTC |
|---|
| Updated | 2026-06-25 09:16:44 UTC |
|---|
| Description | 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 |
|---|
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 45d9bcda21f4c13be75e3571b0f0ef39e77934b5 af80f78ce984649e1698b841cd33f4fa505ad828 git |
Not specified |
| CNA |
Linux |
Linux |
affected 45d9bcda21f4c13be75e3571b0f0ef39e77934b5 8470f676eadeab99132708acb1a85915664d6115 git |
Not specified |
| CNA |
Linux |
Linux |
affected 45d9bcda21f4c13be75e3571b0f0ef39e77934b5 f071b0bf078146368d18e4eec386bf2ddc0ab7e0 git |
Not specified |
| CNA |
Linux |
Linux |
affected 45d9bcda21f4c13be75e3571b0f0ef39e77934b5 2e154b5f53f1b0b490c7b8b02499f90feb86b1d5 git |
Not specified |
| CNA |
Linux |
Linux |
affected 45d9bcda21f4c13be75e3571b0f0ef39e77934b5 3027ecbdb5fdf9200251c21d4818e4c447ef78e1 git |
Not specified |
| CNA |
Linux |
Linux |
affected 4.1 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 4.1 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.143 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.94 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.36 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.0.13 7.0.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/8470f676eadeab99132708acb1a85915664d6115 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/f071b0bf078146368d18e4eec386bf2ddc0ab7e0 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/2e154b5f53f1b0b490c7b8b02499f90feb86b1d5 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/3027ecbdb5fdf9200251c21d4818e4c447ef78e1 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/af80f78ce984649e1698b841cd33f4fa505ad828 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.
