CVE-2025-52565: Linux Foundation runc DoS Vulnerability

CVE-2025-52565 Overview

CVE-2025-52565 is a symlink attack vulnerability in runc, the widely-used CLI tool for spawning and running containers according to the OCI specification. Due to insufficient checks when bind-mounting /dev/pts/$n to /dev/console inside the container, an attacker can trick runc into bind-mounting paths that would normally be read-only or masked onto attacker-writable locations. This vulnerability is conceptually similar to CVE-2025-31133 but targets a different component—specifically the bind-mount of /dev/pts/$n to /dev/console as configured for all containers that allocate a console.

Critical Impact

Container breakout via writable access to sensitive kernel interfaces like /proc/sysrq-trigger or /proc/sys/kernel/core_pattern, enabling host denial of service or arbitrary code execution on the host system.

Affected Products

• Linux Foundation runc versions 1.0.0-rc3 through 1.2.7
• Linux Foundation runc versions 1.3.0-rc.1 through 1.3.2
• Linux Foundation runc versions 1.4.0-rc.1 through 1.4.0-rc.2

Discovery Timeline

• November 6, 2025 - CVE-2025-52565 published to NVD
• December 3, 2025 - Last updated in NVD database

Technical Details for CVE-2025-52565

Vulnerability Analysis

This vulnerability stems from CWE-61 (UNIX Symbolic Link Following), where runc fails to adequately validate bind-mount targets during console setup. When a container allocates a PTY console, runc performs a bind-mount operation from /dev/pts/$n to /dev/console. The vulnerability occurs because this operation happens after pivot_root(2), meaning an attacker who can manipulate the filesystem state can redirect the bind-mount to arbitrary paths.

While direct host file writes are not possible due to the post-pivot_root timing, attackers can leverage this to gain writable access to normally protected kernel interfaces. Specifically, obtaining a writable copy of /proc/sysrq-trigger allows immediate system reboot or kernel panic commands, while writable access to /proc/sys/kernel/core_pattern enables arbitrary code execution when a core dump is triggered.

Root Cause

The root cause is insufficient validation in runc's console allocation code path when performing the bind-mount of the PTY slave device to /dev/console. The code did not properly verify that the target path had not been manipulated via symbolic links or other filesystem tricks before completing the mount operation. This allowed an attacker with local access to craft a malicious container filesystem that redirects the console bind-mount to unintended targets.

Attack Vector

The attack requires local access and user interaction (launching a container with the malicious configuration). An attacker prepares a container image with a specially crafted filesystem that exploits the race condition or path confusion during console setup. When runc processes the container startup and attempts to bind-mount the PTY device, the attacker's crafted symlinks redirect the mount to a sensitive kernel interface, granting the attacker write access to otherwise protected paths.

// Security patch implementing TIOCGPTPEER for safe PTY allocation
// Source: https://github.com/opencontainers/runc/commit/531ef794e4ecd628006a865ad334a048ee2b4b2e

// GetPtyPeer is a wrapper for ioctl(TIOCGPTPEER).
func GetPtyPeer(ptyFd uintptr, unsafePeerPath string, flags int) (*os.File, error) {
	// Make sure O_NOCTTY is always set -- otherwise runc might accidentally
	// gain it as a controlling terminal. O_CLOEXEC also needs to be set to
	// make sure we don't leak the handle either.
	flags |= unix.O_NOCTTY | unix.O_CLOEXEC

	// There is no nice wrapper for this kind of ioctl in unix.
	peerFd, _, errno := unix.Syscall(
		unix.SYS_IOCTL,
		ptyFd,
		uintptr(unix.TIOCGPTPEER),
		uintptr(flags),
	)
	if errno != 0 {
		return nil, os.NewSyscallError("ioctl TIOCGPTPEER", errno)
	}
	return os.NewFile(peerFd, unsafePeerPath), nil
}

Source: GitHub runc Commit

Detection Methods for CVE-2025-52565

Indicators of Compromise

• Unexpected modifications to /proc/sys/kernel/core_pattern from within container processes
• Write attempts to /proc/sysrq-trigger originating from container namespaces
• Anomalous bind-mount operations during container startup that target kernel pseudo-filesystems
• Container processes with unexpected access to host /proc or /sys paths

Detection Strategies

• Monitor container runtime logs for unusual bind-mount operations during container initialization
• Implement file integrity monitoring on critical kernel interfaces (/proc/sysrq-trigger, /proc/sys/kernel/core_pattern)
• Use audit rules to detect mount(2) syscalls with suspicious source/target combinations
• Deploy runtime security agents that detect container escape attempts via kernel interface manipulation

Monitoring Recommendations

• Enable detailed logging for runc and container runtimes to capture console allocation events
• Configure alerts for any write operations to /proc/sysrq-trigger or core_pattern changes
• Monitor for containers requesting PTY allocation with unusual filesystem layouts
• Track runc version deployments across infrastructure and flag vulnerable versions

How to Mitigate CVE-2025-52565

Immediate Actions Required

• Upgrade runc to patched versions: 1.2.8, 1.3.3, or 1.4.0-rc.3 immediately
• Audit all container hosts for vulnerable runc versions using runc --version
• Review container images for suspicious filesystem configurations targeting /dev/console
• Restrict container capabilities and use seccomp profiles to limit mount syscalls

Patch Information

The vulnerability has been fixed in runc versions 1.2.8, 1.3.3, and 1.4.0-rc.3. The patches implement safer PTY allocation using TIOCGPTPEER ioctl and add additional validation during the console bind-mount process. Multiple commits address different aspects of the fix:

• Primary security fix for PTY peer allocation
• Console fallback handling for older kernels
• Device inode creation hardening

For full details, see the GitHub Security Advisory GHSA-qw9x-cqr3-wc7r.

Workarounds

• Disable PTY allocation for containers where interactive console access is not required
• Use read-only container root filesystems to prevent attacker manipulation of mount targets
• Apply strict seccomp profiles that block unnecessary mount-related syscalls
• Implement namespace isolation policies that prevent containers from accessing host /proc filesystems

# Check current runc version and upgrade
runc --version

# For systems using containerd
# Update containerd configuration to use patched runc
# Example: Verify runc binary path
containerd config dump | grep runc

# Apply restrictive seccomp profile to limit mount operations
# In container runtime configuration, add:
# "seccomp": {
#   "defaultAction": "SCMP_ACT_ERRNO",
#   "syscalls": [
#     {
#       "names": ["mount", "umount2"],
#       "action": "SCMP_ACT_ALLOW",
#       "args": []
#     }
#   ]
# }