## https://sploitus.com/exploit?id=0F791A8F-6EAD-5EAB-8510-775EC1066789
# CVE-2026-59346 — VMXNET3 TSO Integer Overflow (VMware Workstation / Fusion)
Proof-of-concept for a 32-bit integer overflow in the VMXNET3 virtual NIC's TSO segmentation path in `vmware-vmx`, reachable from a guest VM.
**This issue is patched.** The PoC is published for research and defensive purposes only. It triggers a host-side crash (SIGSEGV) and does not attempt code execution.
| | |
|---|---|
| CVE | [CVE-2026-59346](https://www.zerodayinitiative.com/advisories/ZDI-26-647/) |
| Writeup | [cyberstan.co.uk/vmxnet3-tso-overflow](https://cyberstan.co.uk/vmxnet3-tso-overflow/) |
| ZDI advisory | ZDI-26-647 |
| Vendor advisory | VMSA-2026-0007 |
| CVSSv3 | 9.3 (vendor) / 7.5 (ZDI) |
| Fixed in | Workstation / Fusion 26H1u1 |
| Reported via | Trend Micro Zero Day Initiative |
## 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](https://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.
```sh
# Inside the guest VM, as root:
# Kernel headers
apk add linux-virt-dev # Alpine
# apt install linux-headers-$(uname -r) # Debian / Ubuntu
make
insmod vmxnet3_tso_trigger.ko
```
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
| Parameter | Default | Purpose |
|---|---|---|
| `ifname` | `eth0` | Interface backed by the VMXNET3 adapter |
| `dryrun` | `0` | `1` writes the descriptors but skips the doorbell, so nothing is triggered |
| `wait_ms` | `0` | Delay in ms between descriptor setup and the doorbell write |
| `txwarm` | `0` | TSO packets to push through the ring before the overflow packet |
| `warmup` | `0` | Host-side allocations to issue before triggering |
| `freechunk` | `0` | Same-size allocations to make and partially release before triggering |
`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:
```sh
insmod vmxnet3_tso_trigger.ko dryrun=1
dmesg | tail -20
rmmod vmxnet3_tso_trigger
```
Expected output includes the computed geometry and the located TX ring:
```
tso_v8: per_seg=6240 (0x1860), HDR_TOTAL=6222, MSS=1
tso_v8: PARAMS: alloc=... overflow=... seg_count=... paylen=...
tso_v8: ring at priv+N: base=... sz=... n2f=... gen=...
tso_v8: DRYRUN -- descriptors written but NOT triggered
```
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:
```sh
insmod vmxnet3_tso_trigger.ko ifname=eth1
```
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:
```sh
dmesg -w
```
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
| | |
|---|---|
| Host | Ubuntu 24.04 LTS, kernel 6.17.0, glibc 2.39 |
| Hypervisor | VMware Workstation Pro 25.0.1 (build 25219725) |
| Guest | Alpine Linux, kernel 6.12, VMXNET3 NIC |
Symbol offsets referenced in the analysis are specific to build 25219725. The vulnerable pattern is the same across builds, but offsets will differ.
## Contents
```
vmxnet3_tso_trigger.c trigger module
Makefile out-of-tree kernel module build
```
## 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
| Date | Event |
|---|---|
| 2026 | Reported to Trend Micro ZDI |
| Sept 2026 | Patched by Broadcom in 26H1u1 (VMSA-2026-0007) |
| Sept 2026 | ZDI-26-647 published |
## 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](https://cyberstan.co.uk) · [@0xCyberstan](https://github.com/0xCyberstan)