OVSwrap: another Linux local root vulnerability · Hey, it's Asim

&darr;<br>Skip to main content

Hey, it&rsquo;s Asim

Table of Contents

Table of Contents

TLDR: OVSwrap (CVE-2026-64531) is a non-universal (but broad) Linux LPE found by giving LLMs the tools to reason through memory safety issues&rsquo; geometry (coupled with CIFSwitch-discovery-style graph reasoning tools). Read on for affected distros, mitigations, and vulnerability details.

Background

In CIFSwitch, we gave models the tools to build and navigate semantic graphs – and got a nice multihop logical vulnerability chain in return. I like deterministic logic bugs: they are elegant and reliable. Memory bugs, OTOH, almost always involve grooming, indeterminism, and the chance to crash the host if you don&rsquo;t place things right. It also doesn&rsquo;t help that (open) LLMs, in my experience, are just not that good at reasoning about memory issues (finding an overflow is one thing, but thinking &lsquo;geometrically&rsquo; to groom the memory for an exploit is another).

My taste preferences aside, I figured – why not try and solve LLMs&rsquo; blindspots&rsquo; with tools once again? I settled on something extremely basic: forcing the hunter agents to keep a persistent state of the relevant geometric structures via ASCII diagrams, at each state of iteration. E.g., as a trivial example for heap/allocators (pretend tcaches, arena *bins, etc., do not exist):

address slot contents<br>──────────────────────────────────────────────────────────────<br>0x1000 S0 [ A0 ]<br>0x1100 S1 [ A1 ]<br>0x1200 S2 [ FREE ]<br>0x1300 S3 [ OVERFLOWING BUF ]<br>0x1400 S4 [ FREE ] 0x1500 S5 [ A5 ]<br>0x1600 S6 [ A6 ]<br>0x1700 S7 [ FREE ]<br>──────────────────────────────────────────────────────────────

and

C100 free list:

HEAD<br>[S7 @ 0x1700] -> [S2 @ 0x1200] -> [S4 @ 0x1400] -> NULL<br>|-- target hole

and the equivalent for within-buffer visualizations (which is what will ultimately matter below).

Proprietary LLMs were clever enough to track these via text files; some open-source ones resisted, so I just straightjacketed them into bolting on the relevant diagrams via grammar-like rules (in general, you can do really fun things when you control the token generation!). Coupling this with the earlier graph building/traversal tool, this got us…

The vulnerability

…a memory bug in the kernel&rsquo;s Open vSwitch, but – in a nice surprise – one that works with the determinism of a logic bug!

TLDR

Open vSwitch accepts a list of &ldquo;actions&rdquo; from userspace and validates/rewrites some of the actions into a larger internal form. These internal actions are stored as Netlink attributes, whose length field is only 16 bits wide.

Now, the total internal action stream is allowed to grow past 64 KiB. But an individual nested action attribute (an attribute and all of its recursive children) still needs to fit in that 16-bit length field. Pre-fix, Open vSwitch did not check that second limit.

As a result, an attacker can submit a valid action (e.g., CLONE) containing hundreds of, say, small conntrack actions. The kernel expands those actions until the generated action is larger than 65,535 bytes, then stores that length in the 16-bit nla_len, causing it to wrap to a small value. Later code trusts the wrapped length, advances by it, and resumes parsing from the middle of the generated conntrack data.

Critically, parts of that conntrack data – labels and timeout names – are controlled by the attacker. And, because the wraparound redirects parsing to a deterministic offset within the same contiguous, attacker-created action stream, forged action headers/payloads can be placed exactly where parsing resumes. Once per-kernel-build offsets are known, no grooming is required.

I reported the issue to security@kernel.org and the Open vSwitch maintainers on June 19, 2026. The fix made it into the stables on July 24. Per the coordinated embargo with linux-distros@, we agreed to publish the writeup/PoC on July 28, 2026, 6am UTC, so that the affected system owners can apply the now-published patches or apply other mitigations. Big thanks to Ilya Maximets and Aaron Conole for OVS-side triage and review and to linux-distros@ for partnering on coordinated disclosure.

Open vSwitch basics

Open vSwitch, or OVS, is a software network switch commonly used by virtualization, cloud, container, and SDN platforms. On Linux, the implementation is split between

ovs-vswitchd in userspace, which decides what flows should exist, and

the kernel, which executes those flows quickly for each packet.

A flow contains a key describing what traffic it matches and a list of actions to perform. Actions do things like:

send the packet through an output port

change packet or tunnel fields

pass the packet through conntrack

clone the packet and run another list of actions

sample traffic

choose different actions based on packet length

Userspace sends these flow keys and action lists to the kernel through Generic...