DeafNews
// 3 CVE · 2 EXPLOIT IN THE LAST 24H→
Linux

ZDI-26-687: Linux Kernel Open vSwitch Use-After-Free Disclosed September 14

Published: Updated: By Samuel Segato 6 min read Linux
Share
WhatsApp Facebook X (Twitter) LinkedIn Reddit Telegram Email
Trend Micro's Zero Day Initiative released advisory ZDI-26-687 on September 14, 2026, detailing a use-after-free in the Linux kernel's Open vSwitch subsystem. A local, low-privileged attacker can exploit the flaw for information disclosure. The fix is already in the torvalds/linux repository, though no CVE has been assigned.

Trend Micro's Zero Day Initiative released advisory ZDI-26-687 on September 14, 2026, documenting a vulnerability in the Linux kernel's Open vSwitch subsystem that allows information disclosure by a local, low-privileged attacker. The official patch, already present in the torvalds/linux repository, demonstrates how a performance optimization introduced a subtle race condition with measurable security impact.

Key Takeaways
  • Advisory ZDI-26-687, released September 14, 2026, documents a use-after-free in the Linux kernel's Open vSwitch subsystem.
  • The attacker requires local access with low-privileged code execution to exploit the flaw, which enables information disclosure.
  • The root cause is a race condition: ovs_flow_tbl_remove() schedules RCU freeing of the mask, but ovs_flow_cmd_fill_info() accesses the pointer without an adequate RCU read lock.
  • The official patch in the torvalds/linux repository (commit 4e30317) reorders operations to eliminate the race window, with 23 additions and 22 deletions in net/openvswitch/datapath.c.

How the Race Condition Works in the Flow Manager

The vulnerability resides in the management of sw_flow_mask objects during flow deletion in the Open vSwitch subsystem. Commit 56c1986, titled "openvswitch: Make flow mask removal symmetric," introduced a change that schedules the mask's RCU freeing immediately after removal from the flow table. However, the pointer remains in the flow structure, accessible within the same RCU critical section.

The problem surfaces in the CMD_DEL command processing path. The function ovs_flow_tbl_remove() removes the flow from the table and schedules the RCU free of flow->mask. Subsequently, ovs_flow_cmd_fill_info() accesses the mask pointer to populate the netlink response. This access occurs without an adequate RCU read lock, creating a race window where the memory may already have been freed.

"The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section."

The analysis in the official commit is explicit: this is a concrete, albeit brief, race condition. Memory allocated for the response information can delay sufficiently to make the race window relevant, resulting in a system crash under load.

The Exploit Chain: From Information Disclosure to Privilege Escalation

The ZDI advisory classifies the primary impact as information disclosure. An attacker with the ability to execute low-privileged code on the target system can read previously freed kernel memory, obtaining sensitive information. The use-after-free nature of the bug, however, expands the risk perimeter: the advisory notes the vulnerability can be combined with other flaws to achieve privilege escalation and arbitrary code execution in the kernel context.

No practical demonstration of this escalation or public exploit is documented. The brief reports no evidence of in-the-wild exploitation. Combination with other vulnerabilities remains a plausible theoretical scenario, not a verified compromise.

The Mainline Patch: Analysis of the Fix

Commit 4e30317ff67a2eb12b4d890d39f72fd7e7117d48 in the torvalds/linux repository resolves the vulnerability by reordering operations in the flow deletion path. The fix moves ovs_flow_tbl_remove() after ovs_flow_cmd_fill_info(), ensuring the netlink response is populated while the mask pointer is still valid. This reordering simultaneously eliminates the need for a forced cast and a purely cosmetic RCU read lock section.

The patch, signed off by Ilya Maximets of OVN.org and reviewed by Aaron Conole of Red Hat, is compact: 23 additions and 22 deletions in net/openvswitch/datapath.c. The bug was originally reported to Trend Micro's Zero Day Initiative as ZDI-CAN-32042, with a vendor report dated August 12, 2026, and coordinated release on September 14, 2026.

"ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock."

The 33-day window between report and public disclosure indicates a functional coordinated disclosure process, with the patch ready before publication. This sequence represents a positive standard for vulnerability management in the open-source kernel.

  • Verify whether systems in use run a Linux kernel with the Open vSwitch subsystem active and determine if commit 4e30317 is included in the distributed version.
  • Contact the Linux distribution vendor to confirm the backport status of the patch, as the commit is in mainline but the status of backports is not documented in the sources.
  • Assess patching priority based on Open vSwitch exposure in multi-tenant or cloud environments, where kernel compromise exposes the entire node.
  • Review local access policies on nodes running workloads with Open vSwitch, given the exploit requires the precondition of low-privileged code execution.

Why This Flaw Reveals a Broader Pattern

ZDI-26-687 illustrates a recurring pattern in Linux kernel evolution: performance optimizations that reduce locking granularity can introduce subtle race conditions with variable activation latency. Commit 56c1986 eliminated the use of ovs_mutex for ovs_flow_free to improve symmetry in mask removal, but did not adequately replicate access guarantees in the netlink notification path.

The discovery via Trend Micro's Zero Day Initiative, with coordinated disclosure and a pre-staged patch, offers an operational model for managing vulnerabilities in critical network subsystems. The lack of an assigned CVE and explicit CVSS score in the ZDI advisory, however, leaves a gap in standard traceability that security teams must bridge by directly verifying the commit in mainline.

Frequently Asked Questions

Is remote access required to exploit this vulnerability?
No. The ZDI advisory specifies the attacker must first obtain the ability to execute low-privileged code on the target system. The exploit is local.
Does a CVE identifier exist for this vulnerability?
None exists. Advisory ZDI-26-687 does not report a CVE ID, and no source in the dossier documents its assignment. Traceability occurs via the ZDI identifier and the patch commit.
Which Linux kernel versions are affected?
The ZDI advisory does not list specific versions. The commit that introduced the vulnerability is 56c1986; the fix is in commit 4e30317 of the torvalds/linux repository. Verifying the presence of the fix requires direct inspection of the commit history in the distributed version.

Information verified against cited sources and current as of publication.

Sources

Sources and references
  1. zerodayinitiative.com
  2. github.com