A missing upper-bound check in the udpifsetthreads() function of Open vSwitch v3.6.90 allows an attacker with OVSDB write access to request an excessive number of handler or revalidation threads. This can cause a denial of service (DoS) via resource exhaustion.
Description ===========
Multiple versions of Open vSwitch are vulnerable to crafted FTP payloads causing invalid memory accesses, potential denial of service, and possible remote code execution. This impacts the userspace implementation of conntrack. Triggering the vulnerability requires that Open vSwitch has configured conntrack flows specifying the FTP alg handler. Conntrack handlers in userspace are not automatically applied.
The issue is caused by type narrowing when copying FTP substrings. It has existed in all versions of the userspace conntrack supporting the FTP handler. This was introduced with Open vSwitch version 2.8.0 and affects all versions up to 3.7.0.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned CVE-2026-34956 identifier to this issue. At the time of writing the flaw is considered with Moderate impact and 5.9 CVSS.
Mitigation ==========
For any affected version of Open vSwitch, avoiding the FTP alg will prevent the issue from triggering. The Open vSwitch team does not recommend attempting to mitigate the vulnerability this way because it may impact packet forwarding.
By default, alg handlers are not installed, and must be added as part of the OpenFlow rules (via 'ct(alg=ftp)' for example).
Users can check if they are using affected flows by looking at their OpenFlow ruleset for their bridges, for example:
ovs-ofctl dump-flows <bridge> | grep 'alg=ftp'
We have found that Open vSwitch may be subject to heap corruption when processing FTP messages.
Fix ===
Patches to fix this vulnerability in Open vSwitch 3.3 and newer are applied to the appropriate branches, and the original patch is located at:
https://mail.openvswitch.org/pipermail/ovs-dev/2026-March/431425.html
Recommendation ==============
We recommend that users of Open vSwitch apply the included patch, or upgrade to a known patched version of Open vSwitch. These include:
3.3.9 3.4.6 3.5.4 3.6.3 3.7.1
Acknowledgements ================
The Open vSwitch team wishes to thank the reporter:
Seiji Sakurai <Seiji.Sakurai () outlook com>
A flaw was found in Open vSwitch. When Open vSwitch is configured with a conntrack flow using FTP helpers over the userspace datapath, a remote attacker can send a specially crafted FTP stream with an EPASV command exceeding 255 characters. This heap access error can lead to a crash, resulting in a Denial of Service (DoS) for the affected system.
A flaw was found in Open vSwitch. When Open vSwitch is configured with a conntrack flow using FTP helpers over the userspace datapath, a remote attacker can send a specially crafted FTP stream with an EPASV command exceeding 255 characters. This heap access error can lead to a crash, resulting in a Denial of Service (DoS) for the affected system.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix memory leak at failed datapath creation
ovsdpcmdnew()->ovsdpchange()->ovsdpsetupcallportids() allocates array via kmalloc. If for some reason newvport() fails during ovsdpcmdnew() dp->upcallportids must be freed. Add missing kfree.
Kmemleak example: unreferenced object 0xffff88800c382500 (size 64): comm "dumpstate", pid 323, jiffies 4294955418 (age 104.347s) hex dump (first 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovsdpsetupcallportids+0x38/0xa0 [<000000000187d8bd>] ovsdpchange+0x63/0xe0 [<000000002397e446>] ovsdpcmdnew+0x1f0/0x380 [<00000000aa06f36e>] genlfamilyrcvmsgdoit+0xea/0x150 [<000000008f583bc4>] genlrcvmsg+0xdc/0x1e0 [<00000000fa10e377>] netlinkrcvskb+0x50/0x100 [<000000004959cece>] genlrcv+0x24/0x40 [<000000004699ac7f>] netlinkunicast+0x23e/0x360 [<00000000c153573e>] netlinksendmsg+0x24e/0x4b0 [<000000006f4aa380>] socksendmsg+0x62/0x70 [<00000000d0068654>] syssendmsg+0x230/0x270 [<0000000012dacf7d>] syssendmsg+0x88/0xd0 [<0000000011776020>] syssendmsg+0x59/0xa0 [<000000002e8f2dc1>] dosyscall64+0x3b/0x90 [<000000003243e7cb>] entrySYSCALL64afterhwframe+0x63/0xcd
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix unsafe attribute parsing in outputuserspace()
This patch replaces the manual Netlink attribute iteration in outputuserspace() with nlaforeachnested(), which ensures that only well-formed attributes are processed.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nlalen(ovskey) if the data is smaller than the netlink header. Check that the attribute is OK first.
In the Linux kernel, the following vulnerability has been resolved:
Revert "openvswitch: switch to per-action label counting in conntrack"
Currently, ovsctsetlabels() is only called for confirmed conntrack entries (ct) within ovsctcommit(). However, if the conntrack entry does not have the labelsext extension, attempting to allocate it in ovsctgetconnlabels() for a confirmed entry triggers a warning in nfctextadd():
WARNON(nfctisconfirmed(ct));
This happens when the conntrack entry is created externally before OVS increments net->ct.labelsused. The issue has become more likely since commit fcb1aa5163b1 ("openvswitch: switch to per-action label counting in conntrack"), which changed to use per-action label counting and increment net->ct.labelsused when a flow with ct action is added.
Since there’s no straightforward way to fully resolve this issue at the moment, this reverts the commit to avoid breaking existing use cases.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix flow memory leak in ovsflowcmdnew
Syzkaller reports a memory leak of newflow in ovsflowcmdnew() as it is not freed when an allocation of a key fails.
BUG: memory leak unreferenced object 0xffff888116668000 (size 632): comm "syz-executor231", pid 1090, jiffies 4294844701 (age 18.871s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000defa3494>] kmemcachezalloc include/linux/slab.h:654 [inline] [<00000000defa3494>] ovsflowalloc+0x19/0x180 net/openvswitch/flowtable.c:77 [<00000000c67d8873>] ovsflowcmdnew+0x1de/0xd40 net/openvswitch/datapath.c:957 [<0000000010a539a8>] genlfamilyrcvmsgdoit+0x22d/0x330 net/netlink/genetlink.c:739 [<00000000dff3302d>] genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] [<00000000dff3302d>] genlrcvmsg+0x328/0x590 net/netlink/genetlink.c:800 [<000000000286dd87>] netlinkrcvskb+0x153/0x430 net/netlink/afnetlink.c:2515 [<0000000061fed410>] genlrcv+0x24/0x40 net/netlink/genetlink.c:811 [<000000009dc0f111>] netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] [<000000009dc0f111>] netlinkunicast+0x545/0x7f0 net/netlink/afnetlink.c:1339 [<000000004a5ee816>] netlinksendmsg+0x8e7/0xde0 net/netlink/afnetlink.c:1934 [<00000000482b476f>] socksendmsgnosec net/socket.c:651 [inline] [<00000000482b476f>] socksendmsg+0x152/0x190 net/socket.c:671 [<00000000698574ba>] syssendmsg+0x70a/0x870 net/socket.c:2356 [<00000000d28d9e11>] syssendmsg+0xf3/0x170 net/socket.c:2410 [<0000000083ba9120>] syssendmsg+0xe5/0x1b0 net/socket.c:2439 [<00000000c00628f8>] dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 [<000000004abfdcf4>] entrySYSCALL64afterhwframe+0x61/0xc6
To fix this the patch rearranges the goto labels to reflect the order of object allocations and adds appropriate goto statements on the error paths.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: use RCU protection in ovsvportcmdfillinfo()
ovsvportcmdfillinfo() can be called without RTNL or RCU.
Use RCU protection and devnetrcu() to avoid potential UAF.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix leak of nested actions
While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions.
Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovsnlafreeflowactions() just jumps over them leaking the memory.
For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nfcttmplalloc():
actions:clone(ct(commit),0)
Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references.
Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS.
Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively.
New build time assertion should protect us from this problem if new actions will be added in the future.
Unfortunately, openvswitch module doesn't use NLAFNESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.
An issue was discovered in Open vSwitch (OvS) 2.7.x through 2.7.6. The decodebundle function inside lib/ofp-actions.c is affected by a buffer over-read issue during BUNDLE action decoding.
Upstream Patch:
https://nvd.nist.gov/vuln/detail/CVE-2018-17206
An issue was discovered in Open vSwitch (OvS) 2.7.x through 2.7.6, affecting ofprotoruleinsert in ofproto/ofproto.c. During bundle commit, flows that are added in a bundle are applied to ofproto in order. If a flow cannot be added (e.g., the flow action is a go-to for a group id that does not exist), OvS tries to revert back all previous flows that were successfully applied from the same bundle. This is possible since OvS maintains list of old flows that were replaced by flows from the bundle. While reinserting old flows, OvS has an assertion failure due to a check on rule state != RULEINITIALIZED. This would work for new flows, but for an old flow the rule state is RULEREMOVED. The assertion failure causes an OvS crash.
Upstream Patch:
https://github.com/openvswitch/ovs/commit/0befd1f3745055c32940f5faf9559be6a14395e6
An issue was discovered in Open vSwitch (OvS) 2.7.x through 2.7.6, affecting parsegrouppropntrselectionmethod in lib/ofp-util.c. When decoding a group mod, it validates the group type and command after the whole group mod has been decoded. The OF1.5 decoder, however, tries to use the type and command earlier, when it might still be invalid. This causes an assertion failure (via OVSNOTREACHED). ovs-vswitchd does not enable support for OpenFlow 1.5 by default.
Upstream Patch:
https://github.com/openvswitch/ovs/commit/4af6da3b275b764b1afe194df6499b33d2bf4cde