CVE-2026-24054: Kata Containers DOS Vulnerability

CVE-2026-24054 Overview

CVE-2026-24054 is a high-severity vulnerability affecting Kata Containers, an open source project that provides a standard implementation of lightweight Virtual Machines (VMs) designed to 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 this container rootfs, the bind mount causes the rootfs to be detected as a block device, leading to the underlying device being incorrectly hotplugged to the guest VM. This improper handling (CWE-754: Improper Check for Unusual or Exceptional Conditions) can cause filesystem-level errors on the host due to double inode allocation and may result in the host's block device being mounted as read-only.

Critical Impact

This vulnerability can compromise host filesystem integrity through double inode allocation and force the host's block device into read-only mode, potentially causing denial of service conditions and data corruption across the container infrastructure.

Affected Products

• Kata Containers versions prior to 3.26.0
• Systems using containerd with overlay snapshotter
• Container environments utilizing Kata runtime for VM-based isolation

Discovery Timeline

• 2026-01-29 - CVE CVE-2026-24054 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-24054

Vulnerability Analysis

This vulnerability stems from inadequate validation when processing container rootfs mount operations. When containerd encounters a malformed container image or one without any layers, it defaults to bind-mounting an empty snapshotter directory as the container rootfs. The Kata runtime's mount detection logic then incorrectly identifies this bind mount as a block device rather than a directory-based filesystem.

The critical issue occurs in the virtcontainers component where the rootfs type detection fails to account for this edge case. When the runtime detects what it believes to be a block device, it proceeds to hotplug the underlying host block device directly into the guest VM for performance optimization—a feature designed for legitimate storage drivers like devicemapper. However, in this attack scenario, the hotplugged device is not an isolated container storage device but rather a shared host block device.

This leads to filesystem-level corruption through double inode allocation, where both the host and guest attempt to manage the same inodes independently. The host's block device may subsequently be remounted as read-only as a protective measure, causing service disruption.

Root Cause

The root cause is classified under CWE-754 (Improper Check for Unusual or Exceptional Conditions). The vulnerability exists because the Kata runtime does not properly validate the nature of the rootfs mount before determining whether to use block device hotplugging. Specifically, when containerd falls back to using an empty snapshotter directory as a bind mount, the runtime's detection logic in container.go misinterprets this as a block device eligible for direct hotplugging, rather than recognizing it as an exceptional condition requiring different handling.

Attack Vector

The attack is network-accessible (as indicated by the CVSS vector AV:N), requiring an attacker to craft or provide a malformed container image with no layers. When this image is pulled and run on a system using Kata Containers with containerd, the following sequence occurs:

1. The malformed image triggers containerd's fallback behavior
2. An empty snapshotter directory is bind-mounted as the container rootfs
3. Kata runtime misdetects this as a block device
4. The host's underlying block device is hotplugged to the guest VM
5. Both host and guest attempt to access the same filesystem simultaneously
6. Double inode allocation causes filesystem corruption
7. Host block device may be forced into read-only mode

The fix changes the default behavior to disable block device hotplugging:

 DEFENTROPYSOURCE := /dev/urandom
 DEFVALIDENTROPYSOURCES := [\"/dev/urandom\",\"/dev/random\",\"\"]
 
-DEFDISABLEBLOCK := false
+DEFDISABLEBLOCK := true
 DEFSHAREDFS_CLH_VIRTIOFS := virtio-fs
 DEFSHAREDFS_QEMU_VIRTIOFS := virtio-fs
 # Please keep DEFSHAREDFS_QEMU_COCO_DEV_VIRTIOFS in sync with TDX/SNP

Source: GitHub Commit Update

Detection Methods for CVE-2026-24054

Indicators of Compromise

• Unexpected read-only remounting of host block devices
• Filesystem errors in system logs indicating double inode allocation or corruption
• Container failures during rootfs mount operations with empty or malformed images
• Unusual block device hotplug events in Kata runtime logs

Detection Strategies

• Monitor for filesystem corruption warnings in dmesg and /var/log/messages related to inode conflicts
• Audit container image pulls for images with zero or malformed layers
• Implement container image scanning to detect malformed manifests before deployment
• Track block device mount state changes for unexpected read-only transitions

Monitoring Recommendations

• Enable verbose logging in Kata runtime to capture rootfs detection events
• Set up alerts for filesystem remount events, particularly read-only transitions
• Monitor containerd logs for fallback behavior indicators when processing container images
• Implement centralized logging for correlation of container deployment events with filesystem anomalies

How to Mitigate CVE-2026-24054

Immediate Actions Required

• Upgrade Kata Containers to version 3.26.0 or later immediately
• Review running containers for any that may have been deployed from malformed images
• Enable the disable_block_device_use configuration option if unable to upgrade immediately
• Audit container registries for potentially malicious or malformed images

Patch Information

The vulnerability is addressed in Kata Containers version 3.26.0. The fix changes the default value of DEFDISABLEBLOCK from false to true, preventing block device hotplugging for container rootfs by default. This forces the use of virtio-fs for passing the rootfs instead of direct block device access.

For detailed information about the security fix, refer to the GitHub Security Advisory GHSA-5fc8 and the GitHub Commit Update.

Workarounds

• Set disable_block_device_use = true in the Kata configuration file before upgrading
• Implement container image validation policies to reject images with no layers
• Consider temporarily restricting container deployment from untrusted registries
• Use admission controllers to validate container images before scheduling

The configuration change can be applied in the Kata Containers configuration file:

# Disable hotplugging host block devices to guest VMs for container rootfs.
# In case of a storage driver like devicemapper where a container's
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons.
# This flag prevents the block device from being passed to the hypervisor,
# virtio-fs is used instead to pass the rootfs.
# WARNING:
#   Don't set this flag to false if you don't understand well the behavior of
#   your container runtime and image snapshotter. Some snapshotters might use
#   container image storage devices that are not meant to be hotplugged into a
#   guest VM - e.g., because they contain files used by the host or by other
#   guests.
disable_block_device_use = @DEFDISABLEBLOCK@

Source: GitHub Commit Update