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.virtio_fs_extra_args 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 kernel_params 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:
enable_annotations = ["enable_iommu", "virtio_fs_extra_args", "kernel_params", "kernel_verity_params"]
Both virtio_fs_extra_args and kernel_params 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:
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=<kata_managed_path> first, then appends the extra args:
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 that overrides the value. This is processed after clap argument parsing, in the function at main.rs:462: