Critical Linux Kernel Vulnerability Exposes SSH Keys and Shadow Files via Race Condition

The Linux kernel, the core of countless systems worldwide, harbored a subtle but critical vulnerability for nearly six years, allowing unprivileged users to extract highly sensitive files including SSH host private keys and the system's shadow password file. This vulnerability, recently patched with commit 31e62c2ebbfd, represents a fascinating case study in how seemingly small implementation details can create significant security risks.

The ssh-keysign-pwn proof-of-concept demonstrates how this vulnerability can be exploited to extract critical system files.

The Technical Heart of the Vulnerability

At the core of this issue lies a subtle race condition in the process exit mechanism. When a Linux process terminates, it goes through a carefully orchestrated cleanup sequence. The vulnerability emerges specifically because the do_exit() function calls exit_mm() before exit_files(). This creates a brief window where the process has no memory mapping (task->mm == NULL) but still retains its file descriptors.

The critical function __ptrace_may_access() contains a check that is skipped when task->mm == NULL. Normally, this check would prevent certain operations, but in this specific state, it becomes bypassable. During this narrow window, an attacker can leverage the pidfd_getfd(2) system call to steal file descriptors from the exiting process, provided the attacker's UID matches the target process's UID. The pidfd_getfd man page provides more details on this system call.

Exploitation in Practice: Two Key Targets

The researchers behind this PoC identified two particularly valuable targets that exhibit the vulnerable pattern:

SSH Host Key Theft

The ssh-keysign daemon, responsible for SSH challenge-response authentication, follows a dangerous pattern. It opens SSH host private keys (typically /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key, protected with mode 0600) before permanently dropping privileges via permanently_set_uid(). If the system is configured with EnableSSHKeysign=no, the process exits immediately after opening these sensitive keys but before closing the file descriptors.

An attacker can exploit this by racing the process exit and using pidfd_getfd(2) to steal these file descriptors, gaining access to the host's private SSH keys. This would allow an attacker to impersonate the server or potentially decrypt intercepted communications.

Shadow File Extraction

Similarly, the chage utility, used to modify user password expiration information, follows a comparable pattern. When executed with chage -l <user>, it opens /etc/shadow for reading via spw_open(O_RDONLY), then drops privileges completely by calling setreuid(ruid, ruid). During the brief window before the process closes the file descriptor and exits, an attacker can steal it using the same technique.

With access to /etc/shadow, an attacker could extract password hashes and potentially crack them offline, leading to full system compromise.

The Long Road to Discovery

This vulnerability has a particularly interesting history. Security researcher Jann Horn first identified the general file descriptor theft pattern in October 2020, recognizing that the race condition in process exit could be exploited. However, it took until May 14, 2026, for Linus Torvalds to implement the final fix in the Linux kernel.

This six-year gap between the initial pattern recognition and the final fix highlights the challenging nature of race condition vulnerabilities. They are often difficult to reliably exploit, which may have contributed to the delay in addressing this specific issue.

Affected Systems and Impact

The vulnerability affects all Linux kernel versions prior to commit 31e62c2ebbfd, which includes virtually all stable releases as of May 14, 2026. Researchers confirmed the vulnerability on a wide range of distributions:

• Raspberry Pi OS Bookworm (6.12.75)
• Debian 13
• Ubuntu 22.04, 24.04, and 26.04
• Arch Linux
• CentOS 9

The impact of this vulnerability is severe, as it allows unprivileged users to extract files that are critical to system security. SSH host keys, if compromised, could allow attackers to set up man-in-the-middle attacks or impersonate legitimate servers. The /etc/shadow file contains password hashes, which, if obtained, could be subject to offline cracking attacks, potentially leading to full system compromise.

Mitigation and Patching

The definitive fix for this vulnerability is updating the Linux kernel to version 31e62c2ebbfd or later. This patch addresses the root cause by ensuring that the __ptrace_may_access() function performs proper checks even when task->mm == NULL.

For systems that cannot be immediately updated, administrators should consider:

1. Disabling ssh-keysign if not absolutely necessary (by setting EnableSSHKeysign=no in sshd_config)
2. Limiting access to the chage utility
3. Implementing additional access controls where possible

However, these are only partial measures, as the vulnerability could potentially be exploited in other contexts beyond these two specific utilities.

Broader Implications

This vulnerability serves as a reminder of the subtle complexities in operating system kernels and the challenges of securing systems against race conditions. The fact that this issue remained unfixed for six years despite being known to security researchers suggests that reliable exploitation of such race conditions may be more difficult than initially apparent, potentially leading to a lower priority for addressing them.

The case also highlights the importance of the pidfd_getfd(2) system call, introduced in Linux 5.6, which provides a more secure alternative to traditional process descriptor manipulation. While this system call was designed to improve security, it inadvertently provided a new mechanism for exploiting race conditions in process exit handling.

Conclusion

The ssh-keysign-pwn vulnerability represents a fascinating case study in Linux kernel security. It demonstrates how subtle implementation details in complex systems can create significant security risks, and how the interaction between different kernel components can create unexpected vulnerabilities.

For system administrators, this case underscores the importance of keeping kernel systems up to date, as even seemingly obscure vulnerabilities can have significant security implications. For security researchers, it highlights the ongoing importance of examining kernel-level race conditions and the complex interactions between system calls.

As systems continue to grow in complexity, we can expect that similar vulnerabilities will continue to be discovered, making the work of kernel security researchers more important than ever.