CVE-2025-22029 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
exec: fix the racy usage of fs_struct->in_exec
check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve() paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it fails we have the following race:
T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex
T2 sets fs->in_exec = 1
T1 clears fs->in_exec
T2 continues with fs->in_exec == 0
Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 02/14/2026
The vulnerability described in CVE-2025-22029 represents a race condition within the Linux kernel's execution handling mechanism that could potentially compromise system security through improper synchronization of critical filesystem structures. This issue manifests in the interaction between the credential guard mutex and the fs_struct->in_exec flag, which serves as a synchronization primitive to track when processes are in the midst of executing new programs. The flaw exists in the execve system call implementation where the kernel attempts to prevent certain unsafe execution scenarios by using the in_exec flag to signal when a process is transitioning between execution contexts.
The technical implementation of this race condition occurs during the execution of check_unsafe_exec() function which establishes the fs->in_exec flag while holding the cred_guard_mutex, but subsequently allows execve() paths to clear this flag without maintaining the same mutex protection. This creates a temporal window where process execution can fail while still leaving the in_exec flag in an inconsistent state, leading to potential security implications. When the first thread (T1) sets the in_exec flag and then encounters an execution failure, it releases the mutex before clearing the flag, creating an opportunity for a second thread (T2) to acquire the flag and proceed with its own execution attempt while the flag appears to be cleared by the first thread.
The operational impact of this vulnerability extends beyond simple race condition behavior to potentially enable privilege escalation or denial of service attacks through manipulation of the execution state tracking mechanism. The flaw creates a scenario where the kernel's security checks designed to prevent unsafe execution paths may be bypassed or rendered ineffective due to the inconsistent flag state. This vulnerability directly relates to CWE-362 which describes race conditions in concurrent programming, and could potentially be leveraged as part of broader attack vectors in the MITRE ATT&CK framework under techniques related to privilege escalation and execution flow manipulation.
The fix implemented addresses this issue by ensuring that the fs->in_exec flag clearing operation occurs while maintaining the cred_guard_mutex lock, thereby preventing the race condition that could lead to inconsistent execution state tracking. This modification ensures that the synchronization primitive remains effective throughout the entire execution lifecycle, preventing scenarios where one thread might incorrectly perceive that a process is not in execution while another thread has already begun or completed an execution transition. The solution maintains the security properties of the credential guard mechanism while ensuring proper atomicity of the flag manipulation operations, thereby preserving the intended protection against unsafe execution scenarios that the original implementation was designed to prevent.