Kata Containers Block Device Hotplug Vulnerability in Container Runtime

A vulnerability in Kata Containers versions prior to 3.26.0 allows host block devices to be improperly hotplugged into virtual machines (VMs) when a container image is malformed or lacks layers. This issue arises because containerd, the container runtime, defaults to bind-mounting an empty snapshotter directory for the container's root filesystem (rootfs) under these conditions. The Kata runtime then misinterprets this bind mount as a block device, leading to the hotplugging of the underlying device to the guest VM. Such an action can cause filesystem errors on the host due to double inode allocation, potentially resulting in the host's block device being remounted as read-only. This vulnerability affects users of the default overlayfs snapshotter in containerd, particularly those running Kata Containers as a runtime class.

Impact

Exploiting this vulnerability can cause severe filesystem errors on the host, including double inode allocation issues, and may lead to the host's block device being mounted as read-only. Such a condition can disrupt other services and workloads on the same host, with the worst-case scenario being a complete host failure if the boot disk is remounted as read-only.

Reproduction

To reproduce this vulnerability, first install Kata Containers version 3.24.0 and set it up as the container runtime in a Kubernetes environment using k3s. After configuring the runtime class to use Kata, create a pod with an image that has no layers, such as 'ghcr.io/kata-containers/no-layer-image:latest'. Once the pod is scheduled, the Kata runtime will attempt to hotplug the rootfs block device, leading to the described filesystem errors on the host.

Remediation

Users can upgrade to Kata Containers version 3.26.0, which includes a patch for this vulnerability. Instructions for updating can be found in the Kata Containers documentation.