CVE-2026-98388: exec: do_close_on_exec() before taking exec_update_lock
In the Linux kernel, the following vulnerability has been resolved:
exec: docloseonexec() before taking execupdatelock
docloseonexec() currently happens while holding the execupdatelock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of execupdatelock, causing a regression.
docloseonexec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use execupdatelock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock.
To avoid such problems, move docloseonexec() before the execupdatelock 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 docloseonexec() call; there seems to be no file descriptor table access in between.
Affected Software
Event History
Frequently Asked Questions
What environments are most likely to encounter this issue?
Systems where execution closes file descriptors associated with a hung filesystem are at risk of blocked paths that need exec_update_lock. FUSE filesystems that inspect the calling process can also trigger a deadlock scenario.
What conditions are needed for the problem to occur?
The issue requires do_close_on_exec() to block while it is handling close-on-exec file descriptors. The description specifically identifies waiting for a filesystem reply, including interactions with a FUSE filesystem inspecting the caller.
How might an affected system behave?
Code paths that use exec_update_lock can become blocked if the filesystem is hung. A FUSE filesystem attempting to inspect the process that invoked it may deadlock.