CVE-2022-23087 - How Misbehaving bhyve Guests Can Exploit e100’s Checksum Offload to Break Out of the Host

In late 2022, a serious vulnerability was uncovered in FreeBSD's popular bhyve hypervisor, specifically targeting virtual machines using the e100 network device model. Known as CVE-2022-23087, this bug lets a malicious or buggy guest VM overrun allocated memory on the host. In certain configurations, this could result in attackers achieving code execution on the host system, a major breach of the virtual machine security boundary.

This post breaks down in simple terms how the bug works, what makes it dangerous, walks through an example attack, and shares links to official details and resources.

The e100 Device and Checksum Offload

Ethernet “e100” virtual adapters are emulated in bhyve to give guest VMs standard networking capabilities. To make networking faster, these model devices (like their real hardware counterparts) include smart processing features:

- Automatic checksum insertion: Calculates and writes IP/TCP checksums into outgoing packets.

TSO (TCP Segmentation Offload): Automatically splits big TCP packets into smaller segments.

These modifications are applied on-the-fly as the guest sends packets through the virtual NIC by copying or modifying network data sitting in memory.

How the Bug Happens

Here’s the key problem: When a guest asks the e100 device to “insert” a checksum into an outgoing packet, the guest VM provides an offset – that is, how far into the packet data to write the computed checksum.

But the bug:
For certain kinds of packets, this offset isn’t properly checked by the e100 code in bhyve. If a guest gives a very large offset, the code will write the checksum value far beyond where it’s supposed to – right into memory used for other things in the hypervisor process.

Since the e100 device model uses an on-stack buffer for the packet headers, a large enough offset will write beyond this stack buffer, and can overwrite critical data, including local variables or even the return address—a classic security no-no.

This is a simplified version of what goes wrong (not actual bhyve source, for illustration)

// Assume hdr has size 128 bytes
uint8_t hdr[128];

// Guest sets checksum offset
int cksum_off = packet_provided_offset;

// Compute and insert checksum (no check on cksum_off)
uint16_t cksum = compute_checksum();

*((uint16_t *)(hdr + cksum_off)) = cksum; // <-- buffer overrun here if cksum_off > 128

Notice that cksum_off comes from the guest, but if it’s larger than 128, we will overwrite memory *after* the end of hdr.

Create a specially crafted packet in the guest, asking for checksum offload.

2. Set the checksum offset field in the offload request to a very large value (for example, 200 bytes - past the end of hdr).
3. When the packet is processed by the e100 emulation code in bhyve, the checksum code writes into the bhyve process’ stack or heap, corrupting memory.
4. With careful design, the attacker can overwrite specific return values, structured exception handlers, or other memory areas needed to hijack program execution—leading (in some cases) to running arbitrary code in the host’s process context.

Depending on the FreeBSD version and how bhyve is configured, the bhyve process may be confined using Capsicum capabilities), which limits what an attacker can do even if the process is hijacked. Still, this bug means a guest can attack the host directly — a serious breach for any hypervisor.

Why This Matters

Most people count on VM isolation as a core part of system security, especially on clouds, hosting providers, or container/VM mixed environments. A bug like this means a guest could:

Or, worse, execute code on the host through the hypervisor, possibly gaining even higher privileges.

If you’re running untrusted or multi-user VMs on bhyve, this is a critical issue.

Who’s Affected?

- FreeBSD systems running bhyve with e100 virtual network adapters *before the patches were released in December 2022* (security advisory FreeBSD-SA-22:16.bhyve).

bhyve guests you don’t fully control or trust.

Notably, *using virtio-net virtual NICs* (the modern default) means you’re NOT vulnerable to this issue.

Upgrade your FreeBSD system and apply all security updates past December 2022.

- Avoid giving untrusted guests access to e100 devices; use virtio-net or other modern devices when possible.

Additional Resources

- NIST CVE-2022-23087 Detail
- FreeBSD Security Advisory FreeBSD-SA-22:16.bhyve
- FreeBSD Bhyve Manual
- Capsicum Capability Framework)

Conclusion

CVE-2022-23087 shows how even subtle mistakes in code that handles guest input in a hypervisor can lead to dangerous vulnerabilities—potentially even breaking the guest/host boundary. As VMs remain a crucial part of both cloud and local infrastructure, keeping up with security advisories and using recommended device models is vital. If you use FreeBSD/bhyve, make sure you're patched!

Timeline

Published on: 02/15/2024 05:15:09 UTC
Last modified on: 12/09/2024 23:24:06 UTC