CVE-2026-98622: net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure

Published Oct 18, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

net/sched: actct: don't WARN on benign flowoffloadalloc() failure

flowoffloadalloc() returns NULL when the conntrack entry is dying (e.g. raced with a conntrack flush) or when the GFPATOMIC allocation fails; both are expected under load and neither is a kernel bug. This path runs from softirq on every committed packet, so with paniconwarn=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 CTDELETE (flush) requests. Hits WARNING: net/sched/actct.c:437 (tcfctflowtableadd(), inlined into tcfctact() 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 erralloc before and after, only the WARN is removed.

Affected Software

1 affected component

Linux Linux kernel

Event History

Oct 18, 2026

CVE Published

via MITRE·03:19 PM

Data Sourced

via MITRE·03:19 PM

Description

Data Sourced

via NVD·04:17 PM

Description

Frequently Asked Questions

Under what conditions can this lead to a system panic?

A panic requires panic_on_warn=1. An unprivileged user must be able to race conntrack flush or CT_DELETE activity against traffic matching a tc classifier using action ct commit, causing flow_offload_alloc() to fail and trigger the warning on an unpatched kernel.

Are failures from flow_offload_alloc() necessarily signs of a kernel fault?

No. The allocation can return NULL when a conntrack entry is dying, such as during a conntrack flush, or when a GFP_ATOMIC allocation fails under load; both conditions are expected.

How can I determine whether a system is affected?

On an unpatched kernel, reproducing the race can produce a WARNING in net/sched/act_ct.c, in tcf_ct_flow_table_add() or tcf_ct_act(). The reported reproduction used UDP flows through tc action ct commit on the loopback interface while flooding ctnetlink CT_DELETE requests.

What can be done if the fix cannot be deployed immediately?

Avoid using panic_on_warn=1 where this risk is unacceptable, and restrict unprivileged users' ability to create or manipulate tc ct commit classifiers and to issue conntrack deletion or flush requests.

CVE-2026-98622: net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure

Affected Software

Event History

Frequently Asked Questions

Under what conditions can this lead to a system panic?

Are failures from flow_offload_alloc() necessarily signs of a kernel fault?

How can I determine whether a system is affected?

What can be done if the fix cannot be deployed immediately?

Company

Resources

Contact

Frequently Asked Questions

Under what conditions can this lead to a system panic?

Are failures from flow_offload_alloc() necessarily signs of a kernel fault?

How can I determine whether a system is affected?

What can be done if the fix cannot be deployed immediately?