CVE-2026-98491: net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry
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 Software
Event History
Frequently Asked Questions
What traffic-processing scenario is required to trigger this issue?
An skb carrying an unconfirmed conntrack entry must be cloned, and both clones must be committed with different extension sets. The described sequence involves one clone committing helpers and another committing labels in the same conntrack zone.
Are normal Open vSwitch deployments likely to be exposed?
The advisory states that no practical network pipeline is known to require committing both unmodified clones into the same zone. It says the change does not affect known use cases, although the condition is possible to trigger.
What happens if the vulnerable sequence occurs?
Adding an extension through the second clone can break a pointer in the expectation list established by the first clone. This can lead to a use-after-free during the later destruction path.
What does the fix do?
When a shared unconfirmed conntrack entry is encountered during commit, the fix resets the entry rather than allowing it to be shared and modified. This avoids the unsafe interaction between cloning and extension modification.