CVE-2026-74347

netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount

HIGH
7.8
CVSS Score
Published: August 15, 2026 at 05:58 AM UTC
Updated: October 21, 2026 at 01:19 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released. Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object. Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed. nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed. nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.450978462300f74dc48aea4a38471cb69bdf741a5
Vendor states this is fixed in 44583fd5735cb0bdf3bfe11b1e51504ce387bdb7 (fixed)
Vendor states this is fixed in 7d6a9cdb8d3a51d9cfe546a09a518ab3d2671549 (fixed)
Vendor states this is fixed in 9aeb0dcfeb460d33d61d434148b51103ab1d2013 (fixed)
Vendor states this is fixed in b2e84317f334d834fb06c9b340ea465f398b6d4f (fixed)
Vendor states this is fixed in 3.4 (unaffected)
Vendor states this is fixed in 6.12.112 (unaffected)
Vendor states this is fixed in 6.18.53 (unaffected)
Vendor states this is fixed in 6.6.160 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card