Live › vulnerability › CVE-2026-98491
Go to dashboardIn the Linux kernel's Open vSwitch conntrack code, a cloned packet with an unconfirmed connection entry can be committed twice with different extensions, leaving a dangling pointer. Freeing that pointer later is a use-after-free, which the sources do not say an attacker can turn into code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts running a Linux kernel with the Open vSwitch module and conntrack commit actions in use, such as Open vSwitch datapath setups with conntrack zones. unknown whether the sources name affected kernel version ranges or whether default configurations trigger it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98491")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.