Learn Cloud Hypervisor - Network Security & Isolation

#Introduction

After understanding the VMM's internal security in episode 12 (virtio, IOMMU, Landlock, seccomp), now we look outward: how VMs are isolated from each other on the network, how firewalls restrict traffic, and what real threats have hit Cloud Hypervisor. One of them is very important to understand: CVE-2026-27211.

Imagine an apartment building: each unit (VM) must have its own door and walls — otherwise one unit's resident could walk into another unit unnoticed. VM network isolation is those walls, and CVE-2026-27211 is an example of how a wall can leak through an unexpected gap.

#Per-VM Network Isolation

#One TAP, One VM

The first isolation principle: every VM has its own TAP (we already covered this in episode 7). No two VMs share the same interface. The unique TAP + unique MAC combination keeps VM traffic from mixing at the L2 layer.

cloud-hypervisor --kernel kernel-vmlinux --disk path=vm-a.raw --net tap=tap-a,ip=192.168.100.1,mac=a8:21:95:80:00:01 --api-socket /tmp/a.sock &
cloud-hypervisor --kernel kernel-vmlinux --disk path=vm-b.raw --net tap=tap-b,ip=192.168.101.1,mac=a8:21:95:80:00:02 --api-socket /tmp/b.sock &

Notice the two VMs use different subnets (192.168.100.x vs 192.168.101.x). With separate bridges, traffic between VMs won't flow without explicit configuration:

sudo ip link add br-a type bridge
sudo ip link add br-b type bridge
sudo ip link set tap-a master br-a
sudo ip link set tap-b master br-b

#Firewall on the Host

A Linux bridge basically doesn't filter. To restrict what may enter/leave a VM, install firewall rules (nftables/iptables) on the host. Here's an example restricting VM-a to talk to VM-b only on a specific port:

nft add table ip vmfw
nft add chain ip vmfw forward { type filter hook forward priority 0 \; }
nft add rule ip vmfw forward iif "tap-a" oif "tap-b" ip daddr 192.168.101.10 tcp dport 443 accept
nft add rule ip vmfw forward iif "tap-a" drop

The rules above: only traffic tap-a → tap-b to port 443 is allowed; all traffic leaving VM-a is dropped. Because the rules live in the forward hook (not the host's input/output), they only affect inter-VM traffic, not the host's own traffic.

#vhost-user Isolation

For vhost-user (episode 7), isolation means the daemon runs in a separate process with limited file descriptors. The daemon only sees the socket and memory region allocated for its VM, not the whole host:

sudo -u chfs virtiofsd --socket-path /tmp/fs-a.sock --shared-dir /srv/vm-a/shared

sudo -u chfs runs the daemon as a non-root user with limited access. The principle is the same as VMM sandboxing: a process with the least privileges needed.

#Case Study: CVE-2026-27211

#The Vulnerability

CVE-2026-27211 is a vulnerability in virtio-block with raw images: a compromised guest could exploit how raw images are mapped (memory-mapped file) to read other files on the host outside the image — cross-VM data exfiltration. Because a raw image is mmap'd directly, a bug in block offset/length handling could let the guest read host file memory that happens to be adjacent.

The impact is serious: tenant A renting a VM could read tenant B's files, or sensitive host files. This is exactly the category of bug that isn't visible until one VM is already compromised.

#The Fix in v50.1

Version v50.1 released a fix for this CVE. The first mandatory step: always run a patched version:

cloud-hypervisor --version
# harus >= v50.1, idealnya versi terbaru (v53.0)

If you're still on a release below v50.1, upgrade immediately. Check the official releases page for patch details and re-verify the binary after updating.

#Mitigations and Workarounds

For those who can't upgrade right away (e.g., waiting for a maintenance window), layer the mitigations:

1. Untrusted/writable images: never use raw images from untrusted sources, and avoid images that are writable and shared between tenants.
2. Read-only backing images: present the base image as readonly=on so the guest can't write:

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=ubuntu.raw,readonly=on \
  --disk path=writable.raw \
  --cpus boot=2 \
  --memory size=2G

3. Landlock workaround: because the CVE involves accessing files beyond the image, restrict the filesystem the VMM can see with Landlock (kernel 5.13+). This limits the file blocks the VMM process can open, so exfiltration can't reach other files on the host.
4. Least privilege principle: run the VMM as a non-root user with minimal setcap (episode 3), not full root.

#Monitoring and Detection

Isolation isn't complete without observation. Watch for suspicious indicators:

auditctl -w /srv/vms/ -p rwxa -k vm-storage
ausearch -k vm-storage --start today

And make sure the VMM runs with the right restrictions:

ps -o user,pid,cmd -C cloud-hypervisor
cat /proc/$(pgrep -f 'cloud-hypervisor' | head -1)/status | grep -E "Seccomp|CapEff"

Seccomp: 2 indicates the filter is active; a minimal CapEff (only cap_net_admin) indicates least privilege is in effect.

#Conclusion

Key takeaways:

• One TAP per VM + separate subnets is the foundation of network isolation.
• A Linux bridge doesn't filter; install firewall rules (nftables) to restrict inter-VM traffic.
• vhost-user isolation means the daemon runs with minimal privileges and limited access.
• CVE-2026-27211: raw image exfiltration via virtio-block, fixed in v50.1.
• Mitigations: patched version, trusted/read-only images, Landlock workaround, least privilege.
• Monitor storage access and VMM seccomp status regularly.

In the next episode, episode 14, we'll cover confidential computing: TDX & SGX — Intel Trust Domain Extensions and Software Guard Extensions, still experimental, the direction of confidential VMs, and how to verify attestation/quote so trusted workloads can run on untrusted infrastructure. VM encryption starts from the CPU.