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
Published: 2026-06-25
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The bug causes ntckets rule handling to treat a template connection‑track entry as a genuine one, copying 16 bytes beyond a stack structure, which can corrupt kernel memory. An attacker could craft network traffic that is processed by the vulnerable nftables rule, potentially leading to arbitrary code execution or a kernel crash, thereby compromising the confidentiality, integrity, and availability of the host.

Affected Systems

All Linux kernels that include the nft_ct subsystem in nftables are affected, including recent 5.x and 6.x series. The vulnerability applies to the standard Linux:Linux product with nftables enabled, with no specific version exclusions noted.

Risk and Exploitability

not available and the vulnerability is not listed in the CISA KEV catalog, suggesting limited public exploitation data. Nevertheless the nature of a kernel stack overflow places this issue at high severity; exploitation requires the ability to deliver crafted packets that trigger the overloaded rule, typically via the network. The risk to systems that run the old nftables configuration is significant, as exploitation could give an attacker kernel privileges.

Generated by OpenCVE AI on June 25, 2026 at 11:44 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to the latest version that includes the upstream patch for the nft_ct stack overflow
  • Immediately review and remove any nftables rules that employ "ct zone set" followed by "ct original" or "ct template" constructs; replace or disable those rules if they are not essential
  • After applying the kernel update or rule changes, restart the nftables service to ensure the new configuration is active

Generated by OpenCVE AI on June 25, 2026 at 11:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 25 Jun 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
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
Title netfilter: nft_ct: bail out on template ct in get eval
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-25T08:39:53.852Z

Reserved: 2026-06-09T07:44:35.395Z

Link: CVE-2026-53267

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-25T11:45:03Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer