Open vSwitch

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays on the Tier 2 OSS-Fuzz row for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Memory-safety work can carry a 2× or 3× multiplier. OVS takes patches by mailing list rather than pull request, sanctions and territory exclusions apply, and one-liner fixes for non-exploitable crashes are not rewarded. CVE history 2 Last 12 months 25 Lifetime Memory safety 40 % Denial of service 30 % Parsing/validation 20 % Access control 5 % Latest advisories Loading the feed Overview Open vSwitch is the virtual switch underneath essentially all of OpenStack Neutron, a very large share of on-premise virtualisation including OpenShift's OVN-Kubernetes, oVirt, Proxmox and XenServer, telco NFV infrastructure and numerous private-cloud offerings. What matters is what it does: OVS is the software that enforces separation between virtual machines belonging to different tenants on the same host. A flow-handling bug there is a cross-tenant traffic leak in a multi-tenant cloud, which puts it in the severity class of a hypervisor escape while attracting a fraction of the research attention. Twenty-five lifetime CVEs against that deployment footprint reads as under-researched. The project pays nothing for a vulnerability report, so sorona.xyz pays you directly on a qualified, reproduced finding. In scope Reports go to [email protected] , which runs the project's documented embargo process under Linux Foundation governance, against the Open vSwitch tree. OVN lives in a separate repository and sits outside that boundary The whole OpenFlow implementation in lib/ofp-* : message decoding, action and match handling, and everything a controller can drive OVSDB in full, covering the JSON-RPC protocol, ovsdb-server , and the schema and transaction handling that forms the configuration trust boundary for an entire fabric The userspace datapath end to end: packet parsing in lib/flow.c and lib/packets.c , action execution, and the megaflow cache and revalidator where a flow-key confusion turns directly into a tenant-isolation failure Every tunnel encapsulation and decapsulation path, including VXLAN, Geneve, GRE and STT The DPDK datapath, a large body of performance-tuned C that parses untrusted packets on the fast path ovs-vswitchd itself, its bridge and port management, and the connection-tracking and NAT integration behind it The command-line and management utilities that parse operator-supplied and controller-supplied input Out of scope OVN ( ovn-org/ovn ), which is a separate repository with no OSS-Fuzz project directory of its own The Linux kernel openvswitch datapath module, which belongs to the kernel scope row rather than to OVS userspace Hypervisor escape claims that are really QEMU or KVM bugs reached through OVS Controller-side defects in OpenDaylight, ONOS or another SDN controller One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude Most-valued findings Memory corruption in the datapath packet parser or a tunnel decapsulation path driven by a single crafted frame. That is the top class here at 40%, and the one that reaches a host process handling every tenant's traffic A flow-key or megaflow cache confusion that delivers one tenant's packets to another, which is the failure OVS exists to prevent and the reason its bugs price like hypervisor escapes OpenFlow or OVSDB JSON-RPC parsing flaws reachable from the control channel, where ovsdb-server is the configuration trust boundary for the whole fabric Memory safety in the DPDK fast path, a large body of hand-tuned C that sees far less review than the packets it parses deserve A remotely triggerable crash of ovs-vswitchd with a real algorithmic cause, since losing the switch takes down every VM on the host at once Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report to the OVS security address, which runs the project's documented embargo process; if it cannot be reproduced it is not eligible Give the maintainers room to ship a fix and publish their advisory before any public writeup OVN lives in a separate repository with no OSS-Fuzz project directory and is not covered by this pathway The Google patch money is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month OVS upstream takes patches through its mailing list rather than through GitHub pull requests, so plan the patch route before you count on the money Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the Open vSwitch maintainers through [email protected] , which runs a documented embargo process under Linux Foundation governance. Fixes ship in a release with a published advisory and researcher credit; hold the detail until then. Nothing in the Patch Rewards rules restricts who may help you prepare or route the report. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability