Summary

The VMXNET3 TSO segmentation routine computes its allocation size as seg_count * per_seg_size using a 32-bit imul. When the true product exceeds 2^32 the result wraps, and the allocator receives the truncated value. The segmentation loop that follows is driven by seg_count, not by the allocation size, so it writes per_seg_size bytes per segment into a buffer sized from the wrapped product.

An earlier fix for this code path (CVE-2025-41236) added bounds checks rejecting packets where MSS, per_seg_size, or their sum exceed 9216. Those checks constrain the individual descriptor fields but never the product, which is the value that actually wraps. Parameters well under the 9216 limit still reach the overflow.

Full root-cause analysis, annotated disassembly and heap geometry: cyberstan.co.uk/vmxnet3-tso-overflow.

Impact

A guest user with sufficient privilege to write raw TX descriptors can cause a large out-of-bounds write in the host vmware-vmx process with content drawn from the guest-supplied packet. In this PoC the write runs until it reaches unmapped memory and the host process dies with SIGSEGV, powering off the VM.

The vendor rated the issue as permitting arbitrary code execution in the hypervisor context; the published PoC demonstrates the memory-safety violation only and stops at the crash.

Affected products

All VMware desktop hypervisor products sharing the vmware-vmx VMXNET3 backend: Workstation, Fusion, and Player. VMXNET3 is the default adapter for modern guests. See VMSA-2026-0007 for the authoritative affected-version list.

Building and running

The PoC is a Linux kernel module that runs inside the guest. It writes VMXNET3 TX ring descriptors directly, bypassing the in-kernel driver's TSO logic, then rings the doorbell MMIO register.

The host vmware-vmx process will crash and the guest will power off. Expect to lose any unsaved state in the VM, and take a snapshot first if you want to re-run it.

Before you start

The guest needs a VMXNET3 adapter. Check with lspci | grep -i vmxnet or confirm ethernet0.virtualDev = "vmxnet3" in the .vmx file. The module talks to the NIC directly, so the interface must be up and bound to the vmxnet3 driver.

Module parameters

warmup and freechunk shape the host heap before the overflow lands. They are not needed to reproduce the crash; leave them at zero unless you are investigating allocation layout.

Suggested sequence

Start with a dry run to confirm the module finds the ring and computes parameters, without touching the host:

Expected output includes the computed geometry and the located TX ring:

If the ring is not found the module logs TX ring not found and aborts. That usually means a driver layout difference; the search heuristic in find_tx_ring() needs adjusting for that kernel.

Then trigger for real, on a non-default interface if needed:

The guest dies with the host process, so the last messages may not reach disk. To capture them, watch the console rather than relying on the journal:

Confirm the crash from the host side in the VM's vmware.log, which will show a PANIC: Unexpected signal: 11 with a backtrace through the allocator on the vcpu-0 thread.

If nothing happens

• Patched host. Anything at 26H1u1 or later rejects the packet. The module will log normally and the VM will keep running.
• Wrong interface. ifname must name the VMXNET3 device, not a bridge or a secondary e1000 adapter.
• Ring too small. The module aborts with need N entries but ring has M slots if the TX ring cannot hold the descriptor chain.

Tested environment

Symbol offsets referenced in the analysis are specific to build 25219725. The vulnerable pattern is the same across builds, but offsets will differ.

Contents

Fix

The multiply needs to be performed in 64 bits, with the result bounded before it reaches the allocator. Capping the individual descriptor fields is not sufficient, since the overflow is a property of the product rather than of either operand.

Disclosure timeline

Use

Published under coordinated disclosure, after a fix shipped. Run it only against systems you own or are authorised to test. It will crash the host hypervisor process, so do not point it at anything you care about.

Author

Stan S - cyberstan.co.uk · @0xCyberstan