CVE-2026-98622 in Linux
Summary
by MITRE • 10/18/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel networking subsystem contains a vulnerability in the connection tracking action handler for traffic control, specifically within the net/sched/act_ct module. This issue arises from an overly aggressive warning mechanism triggered during flow offload allocation failures. The function flow_offload_alloc() is responsible for allocating resources for conntrack entries and may return NULL under specific conditions that are not indicative of a software defect but rather expected operational states. These conditions include scenarios where the connection tracking entry is in the process of dying, such as when racing against a connection track flush operation, or when memory allocation using GFP_ATOMIC fails due to system load. In both cases, the failure is benign and does not represent a bug in the kernel logic itself. However, the presence of a WARN_ON macro in this code path causes the kernel to emit a warning message whenever these conditions are met.
The operational impact of this vulnerability is significant because it can lead to a system panic under certain configuration settings. The affected code path executes from softirq context on every committed packet, making it highly sensitive to timing and load conditions. When the kernel parameter panic_on_warn is enabled, which is common in production environments for strict error monitoring, any warning generated by this function will cause an immediate kernel panic. This effectively allows an unprivileged user to crash the system simply by racing a connection track flush operation against tc commands that commit actions to the connection tracking subsystem. The vulnerability exploits the race condition between packet processing and conntrack table management, turning what should be a recoverable allocation failure into a denial of service event through kernel panic.
The technical flaw is rooted in the misclassification of expected runtime conditions as errors worthy of warning. While flow_offload_alloc() returning NULL indicates that the operation could not proceed, this outcome is anticipated during high load or when entries are being cleaned up concurrently. The original implementation treated these scenarios with a WARN statement to alert developers, but this approach fails to account for normal operational dynamics in busy systems. By removing the warning while preserving the error handling logic, which already included a goto err_alloc branch to handle failures gracefully, the patch ensures that benign conditions do not trigger disruptive warnings. This change maintains system stability without altering the functional behavior of the traffic control actions.
From a security classification perspective, this vulnerability aligns with CWE-390, Detection of Error Condition Without Action, although in this case action is taken but it is inappropriate for the context as it leads to panic. It also relates to CWE-481, Incorrect Assignment instead of Comparison if one considers how conditions are evaluated leading to unintended consequences. In terms of MITRE ATT&CK techniques, this vulnerability can be leveraged via T1053 Scheduled Task/Job or more accurately through resource exhaustion and timing attacks similar to T1499 Endpoint Denial of Service: Overhead Flooding. The attacker utilizes a race condition against system resources (conntrack entries) to trigger the panic mechanism, effectively causing a denial of service without requiring elevated privileges.
Mitigation strategies primarily involve applying the kernel patch that removes the unnecessary WARN_ON statement from net/sched/act_ct.c. For systems where immediate patching is not feasible, administrators can mitigate the risk by ensuring that the panic_on_warn sysctl parameter remains disabled or set to zero in production environments. This prevents warnings from escalating into full system panics, thereby neutralizing the denial of service vector described here. Additionally, monitoring for high rates of conntrack flush operations combined with tc commit actions may help identify potential exploitation attempts before they trigger the vulnerability. Regular updates to the Linux kernel are recommended as this fix has been integrated upstream to prevent such stability issues in future releases.