Cloudanix VulnDB

CVE-2026-98388

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the operating system can let certain file systems freeze the computer when programs start running, making systems less reliable until fixed by an update.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability allows do_close_on_exec() to execute while holding exec_update_lock, permitting blocking filesystem operations (such as FUSE replies) to stall other code paths that rely on the lock for synchronizing process-state access checks, resulting in deadlock or denial of service.

Why it matters to the business

Systems using FUSE-based filesystems or those that may encounter hung filesystems can experience process hangs during program execution, reducing availability and potentially disrupting workloads that rely on reliable exec behavior.

How an attack unfolds

An attacker prepares a FUSE filesystem configured to inspect or delay replies for processes performing exec; when a victim process executes a binary that triggers do_close_on_exec() under the lock, the filesystem interaction blocks the lock and deadlocks dependent kernel paths.

How to fix it

Apply the upstream kernel commit that relocates do_close_on_exec() before acquisition of exec_update_lock; rebuild and deploy updated kernel packages to all affected systems, prioritizing those exposing FUSE mounts.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the kernel source for the reordered do_close_on_exec() call relative to exec_update_lock acquisition, or verify the running kernel version contains the patch and test exec behavior under FUSE workloads for absence of deadlock.

Typical attack path

  1. Mount a malicious or specially crafted FUSE filesystem
  2. Trigger execution of a binary from within a process that causes do_close_on_exec() to run
  3. Filesystem inspection or reply delay blocks while exec_update_lock is held
  4. Deadlock prevents further process-state synchronization and may hang the system or targeted processes

How to detect it

Search kernel logs for hung-task or deadlock warnings involving exec_update_lock or FUSE during process execution; examine audit logs for unusual exec activity originating from FUSE-mounted paths.

What your security team should do

  • Immediately schedule kernel updates for all Linux systems, especially those using FUSE
  • Audit workloads for reliance on FUSE or user-space filesystems and apply compensating controls such as timeouts or alternative mounts where updates are delayed
  • Monitor for kernel oops or hung-task messages related to exec_update_lock

The record

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.

Affected packages

Ecosystem Package Introduced Fixed