CVE-2024-45310: Linuxfoundation Runc Race Condition Flaw

CVE-2024-45310 Overview

CVE-2024-45310 is a race condition vulnerability in runc, the widely-used CLI tool for spawning and running containers according to the OCI specification. This vulnerability affects runc versions 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier. The flaw allows attackers to create empty files or directories in arbitrary locations on the host filesystem by exploiting a race condition with os.MkdirAll when sharing a volume between two containers.

Critical Impact

Attackers with the ability to start containers using custom volume configurations can exploit this race condition to create empty files or directories in arbitrary locations on the host filesystem. This vulnerability is exploitable through runc directly, as well as through Docker and Kubernetes environments.

Affected Products

• Linux Foundation runc versions ≤ 1.1.13
• Linux Foundation runc version 1.2.0-rc1
• Linux Foundation runc version 1.2.0-rc2

Discovery Timeline

• 2024-09-03 - CVE-2024-45310 published to NVD
• 2025-11-25 - Last updated in NVD database

Technical Details for CVE-2024-45310

Vulnerability Analysis

This vulnerability stems from a Time-of-Check Time-of-Use (TOCTOU) race condition in runc's handling of directory creation operations. When runc creates mount points for container volumes, it uses os.MkdirAll without adequate path validation to ensure the operation remains scoped within the container's rootfs boundary. An attacker who can orchestrate the timing of container operations with shared volumes can exploit this race window to trick runc into creating inodes (files or directories) outside the intended container filesystem.

The vulnerability is classified under CWE-61 (UNIX Symbolic Link Following), as the race condition can be leveraged through symlink manipulation during the volume setup process. While the attack cannot truncate or modify existing files, the ability to create arbitrary empty files or directories on the host can facilitate further exploitation scenarios, such as denial of service or privilege escalation chains.

Root Cause

The root cause lies in the use of the standard Go os.MkdirAll function for creating mount point directories without proper containment validation. The function does not inherently verify that all path components resolve to locations within the intended rootfs boundary. When combined with the ability to share volumes between containers and manipulate filesystem state during the race window, this allows path traversal outside the container's root filesystem.

Attack Vector

The attack requires local access and the ability to start containers with custom volume configurations. An attacker must:

1. Create two containers that share a volume
2. Exploit the race window during mount point creation by manipulating symlinks or directory structures
3. Cause os.MkdirAll to follow a path that escapes the rootfs boundary
4. Successfully create empty files or directories in arbitrary host filesystem locations

Containers using user namespaces are still affected, but the scope is significantly reduced as the attacker can only create inodes in directories writable by the remapped root user/group. LSM policies like SELinux or AppArmor can provide additional mitigation.

The security patches introduce a new MkdirAllInRoot utility function that scopes directory creation operations to remain within the container rootfs:

// Security patch in libcontainer/rootfs_linux.go
// Source: https://github.com/opencontainers/runc/commit/63c2908164f3a1daea455bf5bcd8d363d70328c7

 			// inside the tmpfs, so we don't want to resolve symlinks).
 			subsystemPath := filepath.Join(c.root, b.Destination)
 			subsystemName := filepath.Base(b.Destination)
-			if err := os.MkdirAll(subsystemPath, 0o755); err != nil {
+			if err := utils.MkdirAllInRoot(c.root, subsystemPath, 0o755); err != nil {
 				return err
 			}
 			if err := utils.WithProcfd(c.root, b.Destination, func(dstFd string) error {

Detection Methods for CVE-2024-45310

Indicators of Compromise

• Unexpected empty files or directories appearing in sensitive host filesystem locations outside container boundaries
• Anomalous container startup patterns involving rapid volume creation and destruction
• Audit logs showing MkdirAll operations targeting paths outside container rootfs during container initialization
• Unusual symlink creation activity within shared volumes between containers

Detection Strategies

• Monitor container runtime logs for suspicious volume mount operations involving shared volumes between multiple containers
• Implement file integrity monitoring (FIM) on critical host directories to detect unexpected inode creation
• Use container security tools to audit runc version deployments and flag vulnerable instances
• Enable kernel audit rules to track directory creation syscalls from container runtime processes

Monitoring Recommendations

• Deploy runtime security monitoring that can detect filesystem operations escaping container boundaries
• Implement alerting on container configurations that utilize shared volumes between multiple containers
• Monitor for rapid container creation and destruction patterns that could indicate race condition exploitation attempts
• Audit SELinux/AppArmor denials related to runc operations for potential attack indicators

How to Mitigate CVE-2024-45310

Immediate Actions Required

• Upgrade runc to version 1.1.14 or 1.2.0-rc3 or later immediately
• Audit existing container deployments for custom volume configurations that could be exploited
• Enable user namespaces for all containers to limit the scope of potential exploitation
• Review and strengthen SELinux or AppArmor policies applied to container runtimes

Patch Information

The vulnerability is fixed in runc versions v1.1.14 and v1.2.0-rc3. The patches introduce a new MkdirAllInRoot function that properly scopes directory creation operations to remain within the container rootfs boundary. Security commits are available in the runc GitHub repository. Organizations using Docker or Kubernetes should ensure their container runtime is updated to include the patched runc version.

For additional details, refer to the GitHub Security Advisory GHSA-jfvp-7x6p-h2pv and the OSS-Security mailing list announcement.

Workarounds

• Enable user namespaces for containers to restrict inode creation to directories writable by the remapped root user/group
• Apply strict SELinux or AppArmor policies with specific labels for the runc runtime to limit filesystem access scope
• Restrict container configurations that allow volume sharing between multiple containers
• For rootless containers without /etc/sub[ug]id mapping, attackers are limited to world-writable directories only

# Example: Enable user namespaces in Docker daemon configuration
# Edit /etc/docker/daemon.json
cat << 'EOF' > /etc/docker/daemon.json
{
  "userns-remap": "default"
}
EOF

# Restart Docker daemon to apply changes
systemctl restart docker

# Verify user namespace remapping is active
docker info | grep -i "docker root dir"