CVE-2026-98491
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's networking code could let an attacker crash systems or potentially take them over if specific network traffic is processed.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- High
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in Linux kernel Open vSwitch conntrack when an skb carrying a shared unconfirmed ct entry is cloned; the first clone wires helper extensions into the expectation list then loses confirmation, while the second clone adds a labels extension that breaks the pointer, leading to UAF on later destruction.
Why it matters to the business
Kernel memory corruption or crash on affected systems can cause denial of service or potential privilege escalation in network-heavy environments; low public exploitability and five-day-old disclosure reduce immediate risk but require prompt patching of production Linux hosts.
How an attack unfolds
An attacker sends crafted network traffic that triggers conntrack helper processing on cloned skbs sharing an unconfirmed entry; the race between clones corrupts the expectation list pointer, allowing the attacker to trigger the UAF during entry teardown for memory corruption or control-flow hijack.
How to fix it
Apply the upstream kernel commit that resets the ct entry on shared unconfirmed detection during commit; upgrade to a Linux distribution kernel containing the fix once released.
How to confirm the fix worked
Verify the patch is present by checking the git commit that introduced the reset logic for shared unconfirmed entries; confirm no duplicate extension pointers exist for the same unconfirmed ct entry in conntrack code paths.
Typical attack path
- Send packets that engage Open vSwitch conntrack with helpers
- Cause skb cloning while the ct entry remains unconfirmed
- Trigger commit operations on both clones in the same zone
- Force destruction of the corrupted entry to dereference the freed pointer
How to detect it
Review kernel logs for UAF warnings or slab corruption near openvswitch and nf_conntrack modules; inspect network flows involving conntrack helpers and cloned packets for signs of repeated unconfirmed entry commits.
What your security team should do
- Prioritize kernel updates on systems running Open vSwitch with conntrack and helpers
- Monitor upstream stable and distribution kernel advisories for the backported fix
- Temporarily disable unneeded conntrack helpers if immediate patching is delayed
The record
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry In a case where skb with an unconfirmed ct entry gets cloned, we may end up committing both 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 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 committing both clones without modifications into the same zone is needed. So, let's just reset the entry in case for some reason we got an skb with a shared one during commit. This doesn't affect any known use cases, but avoids any potential problems with sharing and modification of the unconfirmed ct entry. 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 |
|---|