Look up another CVE · open CVE-2026-53267 in the interactive tracker
CVE-2026-53267
netfilter: nft_ct: bail out on template ct in get eval
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem net/netfilter. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53267 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/netfilter/nft_ct.c
net/netfilter/nft_ct_fast.c
- What this is
- NETFILTERMAINTAINERS section matched on net/netfilter/ · netfilter-devel@vger.kernel.org · Maintained
- Kernel module
- nft_ct
Check it on the machine
grep -wE 'CONFIG_NETFILTER|CONFIG_NFT_CT' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w nft_ctPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_NETFILTER, CONFIG_NFT_CT
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/netfilter
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.1 | 6.6.143 | af80f78ce984 |
| 4.1 | 6.12.94 | 8470f676eade |
| 4.1 | 6.18.36 | f071b0bf0781 |
| 4.1 | 7.0.13 | 2e154b5f53f1 |
| 4.1 | 7.1 | 3027ecbdb5fd |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code is reached by installing crafted nftables/netfilter rules through NETLINK_NETFILTER and then triggering packet evaluation locally. Remote packets alone cannot install the rule, so this is a local attack vector.
- AC:LAttack complexity, low
- A single crafted rule sequence such as `ct zone set` followed by `ct original saddr` can deterministically trigger the bug on matching packets. No race or external condition beyond the attacker's control is required.
- PR:LPrivileges required, low
- Rule creation requires CAP_NET_ADMIN for the relevant network namespace via nfnetlink. Because nftables is reachable with CAP_NET_ADMIN in a user-created network namespace on systems permitting unprivileged user namespaces, this is low privileges rather than high.
- UI:NUser interaction, none
- After the attacker installs the crafted rule, triggering occurs through packet processing without any victim user action. No user needs to open a file, mount anything, or interact with attacker-controlled content.
- S:UScope, unchanged
- The bug corrupts kernel memory during kernel packet-filter evaluation and impacts the same kernel security authority. This is standard kernel privilege escalation/DoS behavior, not a VM, IOMMU, or distinct security-scope escape.
- C:HConfidentiality impact, high
- The bug is a kernel stack out-of-bounds write past `struct nft_regs`, a memory corruption primitive. Under the required higher-severity rule, such memory corruption is defensibly treated as capable of enabling high confidentiality impact.
- I:HIntegrity impact, high
- The vulnerable 16-byte memcpy can overwrite beyond the validated destination register on the kernel stack. Out-of-bounds kernel writes are high integrity impact because they can plausibly be developed into control-flow or privilege-modification primitives.
- A:HAvailability impact, high
- The stack overwrite can corrupt adjacent stack state or registers during packet evaluation and can crash or oops the kernel. Kernel crash or panic is high availability impact.