CVE-2026-98388 in Linux
Summary
by MITRE • 10/15/2026
In the Linux kernel, the following vulnerability has been resolved:
exec: do_close_on_exec() before taking exec_update_lock
do_close_on_exec() currently happens while holding the exec_update_lock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of exec_update_lock, causing a regression.
do_close_on_exec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use exec_update_lock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock.
To avoid such problems, move do_close_on_exec() before the exec_update_lock is taken, but after the FD table has been copied if necessary.
I have looked through all the calls between the old and new position of the do_close_on_exec() call; there seems to be no file descriptor table access in between.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The Linux kernel vulnerability identified involves a concurrency control flaw within the process execution path, specifically concerning the ordering of operations during an execve system call. The core issue stems from holding the exec_update_lock while invoking do_close_on_exec(), a function responsible for closing file descriptors marked with the close-on-exec flag. This lock is designed to synchronize access checks against various aspects of process state and has been increasingly utilized across multiple code paths that inspect or modify process attributes. By retaining this exclusive lock during the execution of do_close_on_exec(), the kernel inadvertently creates a window where critical synchronization mechanisms are blocked for extended periods, leading to potential system-wide stalls or deadlocks under specific conditions.
The technical flaw is rooted in the blocking nature of file descriptor cleanup operations when interacting with certain filesystem implementations. The function do_close_on_exec() may need to wait for replies from underlying filesystem drivers, particularly those that require network communication or complex I/O handling. If a filesystem becomes unresponsive or hangs, the thread executing execve will block while still holding the exec_update_lock. Since other kernel threads and subsystems rely on this lock to perform essential process state checks and updates, their execution is effectively halted until the blocked operation completes. This creates a denial-of-service scenario where legitimate system operations are suspended due to the actions of a single hung filesystem interaction during an executable load sequence.
A particularly severe manifestation of this flaw occurs with FUSE (Filesystem in Userspace) implementations that attempt to inspect or interact with the calling process during the close-on-exec phase. In such scenarios, the user-space daemon handling the FUSE request may itself need to acquire locks or perform operations that depend on kernel-side synchronization primitives managed by exec_update_lock. This circular dependency results in a classic deadlock situation where neither the kernel thread nor the userspace daemon can proceed. The regression was exacerbated by recent changes that introduced additional use cases for the exec_update lock, thereby increasing the surface area of code paths susceptible to this blocking behavior and raising the probability of encountering such deadlocks in production environments utilizing FUSE or similar networked filesystems.
The operational impact of this vulnerability includes significant performance degradation and potential system instability. Administrators may observe processes hanging indefinitely during execution attempts, leading to application failures and reduced throughput for systems relying on dynamic executable loading. In worst-case scenarios involving recursive locking dependencies with userspace daemons, the entire kernel thread pool handling execve operations could become saturated or deadlocked, effectively rendering parts of the operating system unresponsive. This affects not only local applications but also containerized environments where frequent image pulls and executions are common, potentially impacting cloud infrastructure stability if affected filesystem drivers are utilized for storage backends.
To mitigate this risk, the kernel developers have restructured the execution flow to move do_close_on_exec() before acquiring the exec_update_lock, while ensuring it remains after any necessary duplication of the file descriptor table. This ordering ensures that the heavy-weight blocking operation occurs without holding the critical synchronization lock, thereby allowing other processes and subsystems to continue accessing process state information normally. The fix preserves data integrity by maintaining the correct sequence relative to FD table copying, which is crucial for ensuring that child processes do not inherit stale or inconsistent file descriptor states. This adjustment aligns with best practices in concurrent programming by minimizing the duration of lock hold times for operations that may block on external I/O.
From a standards perspective, this vulnerability maps to CWE-833 Lock Involving Resource, as it involves holding a resource lock during an operation that can lead to indefinite blocking or deadlock. It also relates to CWE-617 Reachable Assertion and potential availability impacts described in common weakness enumerations regarding improper locking protocols. Within the MITRE ATT&CK framework, this flaw could be leveraged for Denial of Service (T1499) by an attacker who can trigger execve calls with hung or maliciously crafted filesystem mounts to exhaust system resources or freeze critical kernel threads. Security practitioners should ensure that systems are updated with patches addressing this specific ordering issue in the Linux kernel, particularly those deploying FUSE-based storage solutions or custom filesystem drivers that interact closely with process execution contexts. Regular auditing of lock acquisition patterns and monitoring for long-held locks can help detect similar concurrency issues before they escalate into full system outages.