CVE-2026-98388

Description

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.

Is your site exposed to CVE-2026-98388?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0022

Probability of exploitation

0.12%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/0d86cd6b709c39216e6ee5ea8f0fc4242bbb2b53 https://git.kernel.org/stable/c/19ddef61ee0a49782a60f8f497e50597ad5de2da https://git.kernel.org/stable/c/3feb4020bfb7ccf0d347f27051639d25e19cd65d https://git.kernel.org/stable/c/550feab5b01000ab314868b62211fb3ddfd600e8 https://git.kernel.org/stable/c/5aacc19ba2b1faf84c4a2f2cf9a1784e03d1ff38 https://git.kernel.org/stable/c/63be3d8511bdafa095cd14a393cbf3c58dbbb928 https://git.kernel.org/stable/c/955973fff4a36d39a848b00cac1706863f568fe1 https://git.kernel.org/stable/c/e780259b54e618ceb4763fbc21314acf3565e813

Frequently Asked Questions

What is CVE-2026-98388? +

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.

How do I check if I'm vulnerable to CVE-2026-98388? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.