Cloudanix VulnDB

CVE-2026-98622

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel networking bug can let an attacker crash the machine by sending ordinary network traffic while also clearing connection tracking entries, provided the system is configured to stop on warnings.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
None

What it actually does

The flaw triggers an unnecessary kernel WARN_ON in tcf_ct_flow_table_add() when flow_offload_alloc() legitimately returns NULL due to a dying conntrack entry or GFP_ATOMIC allocation failure; under panic_on_warn=1 this produces a DoS from softirq context on every committed packet.

Why it matters to the business

Unprivileged local or adjacent attackers can crash Linux systems running tc classifiers with ct commit actions, causing denial of service and operational disruption; low EPSS and no KEV listing reduce immediate urgency but the five-day-old issue still requires prompt kernel updates on exposed hosts.

How an attack unfolds

An attacker creates a tc filter using 'action ct commit' on an interface, generates a modest set of UDP flows, then races bare ctnetlink CT_DELETE flush requests from userspace to hit the NULL return path and emit the warning before the patched kernel removes it.

How to fix it

Upgrade to a kernel containing the commit that removes the WARN_ON call while preserving the existing goto err_alloc behavior; rebuild and reboot affected systems; consider disabling panic_on_warn where operationally acceptable until patched.

How to confirm the fix worked

Confirm the WARN_ON line at net/sched/act_ct.c:437 (or equivalent) is absent in the running kernel source; reproduce the supplied QEMU test case and verify no warning or panic occurs under the same load.

Typical attack path

  1. Install a tc classifier containing 'action ct commit'
  2. Inject a small fixed set of UDP flows through the classifier
  3. Concurrently flood ctnetlink CT_DELETE requests from multiple threads
  4. Trigger the benign flow_offload_alloc() failure path inside softirq

How to detect it

Search kernel logs and dmesg for the string 'WARNING: net/sched/act_ct.c' or the function tcf_ct_flow_table_add under conditions of high conntrack churn or tc ct commit usage; correlate with ctnetlink flush activity.

  • WARNING: net/sched/act_ct.c:437
  • tcf_ct_flow_table_add
  • flow_offload_alloc

What your security team should do

  • Apply the upstream fix to all production kernels within the next maintenance window
  • Audit systems for tc filters using act_ct commit and for panic_on_warn=1
  • Temporarily disable panic_on_warn on high-risk hosts if patching is delayed
  • Add kernel warning telemetry for act_ct paths to SIEM for early detection

The record

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.

Affected packages

Ecosystem Package Introduced Fixed