Introduction
A crafted DHCPv6 packet sent from a tenant VM can trick OVN's ovn-controller into reading past the end of a packet buffer and shipping the resulting heap contents straight back to the attacker. In multi-tenant cloud environments built on OVN, a single malicious workload could silently harvest fragments of host memory that may contain data belonging to other tenants or to the control plane itself.
Open Virtual Network (OVN) is an open-source logical networking layer that translates virtual network configurations into OpenFlow rules for Open vSwitch. It underpins platforms like Red Hat OpenShift, Red Hat OpenStack, and Ubuntu cloud deployments, and it is one of the most widely deployed software-defined networking solutions in production data centers. That reach gives any flaw in OVN's packet-processing path a broad blast radius across the cloud ecosystem.
Technical Information
Root Cause: Trusting Client-Supplied Lengths
The vulnerability lives in OVN's pinctrl userspace thread, which handles control-plane packets, including DHCPv6. When a workload sends a DHCPv6 SOLICIT message (message type 0x01), pinctrl parses the incoming options and builds a DHCPv6 ADVERTISE reply. As part of that reply, the handler echoes the Client ID option back to the requestor.
The code used the Client ID option's self-declared length to decide how many bytes to copy into the reply, and it never checked whether that length fit within the received packet. The copy looked like this:
memcpy(data + data_len, in_opt, opt_len);
Here, opt_len came directly from the option header's length field, which the attacker controls entirely. By setting this length far beyond the actual packet payload (for example, 0x0200 or 512 bytes when the real option data is only a few bytes), the attacker forces ovn-controller to read well past the end of the packet buffer and into adjacent heap memory. That heap content is then faithfully copied into the ADVERTISE reply and delivered back to the attacker's VM port.
This is classified as CWE-130: Improper Handling of Length Parameter Inconsistency.
CVSS Breakdown
The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, for a base score of 8.6. The metrics break down as follows:
| Metric | Value | Meaning |
|---|---|---|
| Attack Vector | Network | Exploitable remotely. The attacker only needs network access to a DHCPv6-enabled logical switch port. |
| Attack Complexity | Low | No race conditions and no special configuration beyond DHCPv6 being enabled. |
| Privileges Required | None | No authentication is needed. Any entity on the network segment can send DHCPv6 SOLICIT packets. |
| Scope | Changed | A flaw in the network controller leaks host memory to a guest VM, which crosses a trust boundary. |
| Confidentiality | High | The attacker can extract arbitrary heap contents from the ovn-controller process. |
| Integrity / Availability | None | The flaw does not allow data modification or service disruption. |
Attack Flow
- The attacker identifies (or already occupies) a VM connected to an OVN Logical Switch Port that has DHCPv6 options configured.
- The attacker crafts a DHCPv6 SOLICIT packet containing a Client ID option (option code
0x0001) with a length field much larger than the actual option payload (e.g., 512 bytes declared, but only a handful of bytes present). - The attacker sends the packet from their VM on UDP port 546/547.
- The
ovn-controller'spinctrlthread receives the SOLICIT, parses the Client ID option, and uses the attacker-supplied length tomemcpydata into the ADVERTISE reply buffer. - Because the declared length exceeds the packet boundary, the copy reads into adjacent heap memory belonging to the
ovn-controllerprocess. - The ADVERTISE reply, now carrying leaked heap data in the echoed Client ID option, goes back to the attacker's VM port.
- The attacker extracts the leaked memory from the reply and can repeat the process to harvest more heap fragments.
Identifying Vulnerable Ports
The vulnerability is only exploitable when DHCPv6 options are configured on a Logical Switch Port. Administrators can check exposure with:
ovn-nbctl --columns name,dhcpv6_options list logical_switch_port
If any port returns a populated dhcpv6_options field, workloads attached to that port can reach the vulnerable code path.
Patch Information
The OVN maintainers fixed CVE-2026-5367 in commit 78f6ce6, cherry-picked from 0e3d1d908b765ca29c6744f22005c60a6f72b76e. Ales Musil wrote the patch, with reporter Seiji Sakurai as co-author. It touches three files: controller/pinctrl.c (186 additions, 117 deletions), lib/ovn-l7.h (10 additions), and tests/system-ovn.at (66 additions for a new regression test), for a total of 262 additions and 117 deletions.
The Core Fix: next_dhcpv6_opt() Iterator
The heart of the fix is next_dhcpv6_opt(), a new centralized option iterator. Before this patch, every DHCPv6 parsing loop in OVN's pinctrl module did its own raw pointer arithmetic to walk the options, and none of them consistently validated the self-declared length field against the real remaining packet size. The new helper performs two bounds checks on every iteration:
static const struct dhcpv6_opt_header * next_dhcpv6_opt(const uint8_t *data, size_t opts_len, size_t *len, size_t *opt_len) { size_t len_inner = *len + sizeof(struct dhcpv6_opt_header); if (len_inner > opts_len) { return NULL; } const struct dhcpv6_opt_header *hdr = (const struct dhcpv6_opt_header *) (data + *len); len_inner += ntohs(hdr->len); if (len_inner > opts_len) { return NULL; } *len = len_inner; *opt_len = sizeof *hdr + ntohs(hdr->len); return hdr; }
First, it checks that there is room for the 4-byte option header itself. Then it reads the declared payload length and verifies that the payload also fits within the remaining data. If either check fails, the function returns NULL and iteration stops cleanly. The patch replaces every earlier ad hoc parsing loop in pinctrl_parse_dhcpv6_advt(), pinctrl_parse_dhcpv6_reply(), and pinctrl_handle_put_dhcpv6_opts() with a for loop driven by this bounds-checked iterator.
Additional Hardening
Beyond the iterator, the patch introduced several defense-in-depth changes:
-
lib/ovn-l7.hgains a properstruct dhcpv6_headerand aDHCPV6_PAYLOAD()macro. They replace the raw+4pointer offset that previously skipped the DHCPv6 message type and transaction ID, so packet dissection is now type-safe and self-documenting. -
pinctrl_handle_dhcp6_server()andpinctrl_handle_put_dhcpv6_opts()now validate packet length up front. Each returns immediately ifdlen < UDP_HEADER_LEN + DHCPV6_HEADER_LEN, so truncated packets are rejected before any option parsing begins. -
Option types now get minimum-size checks. Before casting a raw pointer to
struct dhcpv6_opt_ia_na, for instance, the code ensuresopt_len >= sizeof(struct dhcpv6_opt_ia_na). Similar guards protect the IA_PREFIX, STATUS, USER_CLASS, and FQDN options. -
The check for the
"iPXE"user class string now usesstrncmpinstead of an unboundedstrcmp. That closes a secondary issue where a user-controlled string had no length bound. -
A new helper,
dhcpv6_opt_ia_na_parse_inner(), was factored out to safely parse sub-options inside an IA_NA/IA_PD option. It removes the duplicated inner loops from both the ADVERTISE and REPLY handlers.
Regression Test
The commit adds a system test (DHCPv6 - Options heap overread) that uses Scapy to send a malformed DHCPv6 SOLICIT packet with a Client ID whose declared length (0x0200, or 512 bytes) far exceeds the actual payload. The test checks that ovn-controller logs a warning ("DHCPv6 option - Client id not present") and sends back no ADVERTISE reply.
Patched Releases
| Release Branch | Patched Version |
|---|---|
| 24.03 | v24.03.8 |
| 24.09 | v24.09.4 |
| 25.03 | v25.03.3 |
| 25.09 | v25.09.3 |
| 26.03 | v26.03.1 |
Detection Methods
Exposure Assessment via OVN Configuration
The simplest triage step is to check whether the vulnerable code path is reachable. Run:
ovn-nbctl --columns name,dhcpv6_options list logical_switch_port
If any port returns a populated dhcpv6_options field, that port is configured to respond to DHCPv6 SOLICIT messages and the vulnerable code path is active. Deployments without DHCPv6 options on their logical switch ports are not exposed to this specific attack vector.
Version-Based Detection
All OVN versions prior to v24.03.8, v25.03.3, v25.09.3, and v26.03.1 are vulnerable when DHCPv6 is enabled on logical switch ports. The 24.09 branch did not receive a dedicated fix, and the OVN team recommends upgrading to the next available release for that branch.
Network Traffic Analysis
The attack signature is a DHCPv6 SOLICIT packet (message type 0x01) containing a Client ID option (option code 0x0001) whose declared length is disproportionately large compared with the actual packet payload. For reference, the regression test in the fix commit uses a Client ID with a declared length of 0x0200 (512 bytes), even though the packet contains far less data.
Network monitoring tools that can do deep packet inspection on DHCPv6 traffic (UDP port 546/547) should flag SOLICIT messages where any option's declared length, especially Client ID (option code 1), extends beyond the remaining bytes in the UDP payload. Repeated SOLICIT messages from a single source with varying, inflated Client ID lengths would be a particularly strong sign of exploitation attempts.
Post-Patch Log Monitoring
Once the patch is applied, ovn-controller logs a specific warning when it sees packets that lack a valid Client ID option, including packets that fail the new bounds validation. The message to watch for is:
DHCPv6 option - Client id not present
A spike in these warnings, especially one correlated with specific VM ports, would suggest active probing or exploitation attempts against the now-patched code path.
Response-Side Indicators
On unpatched systems, defenders can look for anomalous DHCPv6 ADVERTISE replies where the echoed Client ID option holds significantly more data than a legitimate DUID (DHCPv6 Unique Identifier, typically well under 128 bytes). Packet captures of the affected logical switch port's traffic may show these oversized Client ID echoes in ADVERTISE messages.
Affected Systems and Versions
The vulnerability affects all OVN versions prior to the patched releases listed below. It is only exploitable when DHCPv6 options are configured on at least one Logical Switch Port.
OVN Upstream:
| Branch | Vulnerable | Patched |
|---|---|---|
| 24.03.x | All versions before v24.03.8 | v24.03.8 |
| 24.09.x | All versions (upgrade to next branch recommended) | v24.09.4 |
| 25.03.x | All versions before v25.03.3 | v25.03.3 |
| 25.09.x | All versions before v25.09.3 | v25.09.3 |
| 26.03.x | All versions before v26.03.1 | v26.03.1 |
Downstream Vendors:
| Vendor | Product | Status |
|---|---|---|
| Red Hat | Fast Datapath for RHEL 7, 8, 9 | All versions affected by default |
| Red Hat | OpenShift Container Platform 4 | All versions affected by default |
| Ubuntu | 26.04 LTS, 25.10, 24.04 LTS, 22.04 LTS, 20.04 LTS | Currently marked as "Needs evaluation" |
References
- NVD: CVE-2026-5367
- CVE Record: CVE-2026-5367
- Red Hat Security Advisory: CVE-2026-5367
- Red Hat Bugzilla: 2455863
- OVN Fix Commit 78f6ce6
- oss-security: Heap over-read in OVN DHCPv6 Client ID processing
- oss-security (seclists): Advisory
- oss-security (seclists): Follow-up
- OVN Announce Mailing List
- Debian Security Tracker: CVE-2026-5367
- Ubuntu Security: CVE-2026-5367
- OVN Project Documentation
- OVN GitHub Repository
- Red Hat OpenStack: Networking with OVN



