Live › vulnerability › CVE-2026-98622
Go to dashboardA kernel warning fires in the traffic-classifier conntrack action when a flow allocation fails during a conntrack flush, which is expected under load. On systems with panic_on_warn=1, a local user racing a conntrack flush against a tc ct commit filter can crash the machine.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems that use tc with the act_ct action (ct commit in traffic classifiers) and run kernels that still contain the WARN. The panic needs kernel.panic_on_warn=1, which is not the default, so hosts with default settings only see a logged warning. Hosts that do not use tc ct actions are not affected.
No product ranges from the sources yet.
uname -r and compare against the kernel release that contains the upstream commit removing the WARN in net/sched/act_ct.csysctl kernel.panic_on_warn (value 1 is the exposed setting)tc filter show dev <iface> to see whether any filter uses action ct commitsysctl -w kernel.panic_on_warn=0 if it is 1Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure
flow_offload_alloc() returns NULL when the conntrack entry is dying
(e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation
fails; both are expected under load and neither is a kernel bug. This
path runs from softirq on every committed packet, so with
panic_on_warn=1 an unprivileged user can panic the box just by racing
a conntrack flush against a tc ... action ct commit classifier.
Reproduced with a custom repro under QEMU: a small, fixed set of UDP
flows through tc filter ... action ct commit on lo, raced against
threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits
WARNING: net/sched/act_ct.c:437 (tcf_ct_flow_table_add(), inlined
into tcf_ct_act() in this build) within ~15s on the unpatched kernel;
same setup is clean on the patched kernel. The fix itself is
behavior-preserving: both branches already did goto err_alloc
before and after, only the WARN is removed.
This page as .md · .json · in your agent: get_signal("CVE-2026-98622")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.