Cloudanix VulnDB

CVE-2026-98441

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network connection tracking code could let specially crafted traffic corrupt memory and crash systems or allow attackers to gain elevated access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel act_ct when a cloned skb with an unconfirmed conntrack entry causes one clone to wire extension pointers into the expectation list while a second clone reallocates extensions for labels or NAT, leaving dangling pointers that are dereferenced on destruction.

Why it matters to the business

Potential kernel memory corruption on systems processing complex conntrack NAT or helper traffic, which can cause crashes, service disruption, or in rare cases local privilege escalation; low public exploitability but high impact if triggered in production network paths.

How an attack unfolds

An attacker sends crafted packets that trigger skb cloning inside act_ct while an unconfirmed conntrack entry exists; the first clone commits helpers and then loses confirmation, the second clone then installs new extensions, breaking the shared pointer and enabling UAF later during expectation cleanup.

How to fix it

Upgrade to a kernel containing the referenced fix that resets the ct entry when a shared unconfirmed entry is detected; rebuild and deploy the updated kernel image across all affected hosts; test NAT and helper configurations in staging before production rollout.

How to confirm the fix worked

Confirm the patch is present by inspecting the act_ct source for the reset-on-shared-unconfirmed logic; run kernel selftests for conntrack NAT and helpers; monitor for crashes in nf_conntrack or act_ct after upgrade.

Typical attack path

  1. Send network traffic that enters act_ct with unconfirmed conntrack entry
  2. Trigger skb clone operation inside the same conntrack zone
  3. First clone performs helper commit then drops confirmation
  4. Second clone performs NAT or label commit, reallocating extension space
  5. Trigger expectation list destruction to dereference freed pointer

How to detect it

Review kernel logs for oops or panic messages referencing nf_conntrack, act_ct, or expectation list destruction; inspect network packet captures for repeated skb clones on the same flow without zone or header changes.

What your security team should do

  • Prioritize kernel updates on any hosts using act_ct with NAT or conntrack helpers
  • Audit network pipelines for skb cloning combined with unconfirmed entries
  • Add kernel memory corruption monitoring and crash-dump collection
  • Re-test high-throughput NAT or stateful firewall configurations post-update

The record

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: avoid modifying shared unconfirmed ct entry In a case where skb with an unconfirmed ct entry gets cloned, we may end up processing both again but with different sets of extensions. The series of events: 1. The first clone wants to commit and runs the helpers wiring up the extension pointer into the expectation list. 2. Then it looses the confirmation keeping the entry unconfirmed. 3. Second clone now wants to commit labels or run NAT and adds the new extension for that breaking the pointer in the expectation list causing UAF on the destruction path later. While this is possible to trigger, there should be no practical network pipeline where we need to process both clones without modifications in the same zone. So, let's just reset the entry in case for some reason we got an skb with a shared one. This doesn't affect any known use cases, but avoids any potential problems with sharing and modification of the unconfirmed ct entry. Unlike openvswitch module, act_ct allows for NAT without commit. Changing that would be a uAPI break. So, act_ct needs to reset on NAT regardless of the commit flag to avoid reallocation of the extension space. This, however, doesn't really change the picture for sensible networking cases as there should be no need to run the same packet twice (before and after the clone) through conntrack without packet header or zone changes and without commit. The fixes tag points to the introduction of helpers, since that's the main UAF trigger for the sharing.

Affected packages

Ecosystem Package Introduced Fixed