CVE-2026-99181 in Linuxinfo

Summary

by MITRE • 10/28/2026

In the Linux kernel, the following vulnerability has been resolved:

autofs: ignore notification errors from a replaced pipe

autofs_notify_daemon() takes a reference to the current notification pipe under wq_mutex, then drops the mutex before writing the request. The write can block while the daemon enters catatonic mode and installs a replacement pipe.

If the old pipe's reader is then closed, the delayed write returns -EPIPE and the generic error path enters catatonic mode again. That transition acts on the current superblock state, closes the replacement pipe, and releases the new daemon generation's wait queues.

Only enter catatonic mode when the pipe which failed is still the current pipe. Factor the already-locked transition so the identity check and state change are atomic with respect to another replacement.

This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest. An unprivileged UID 65534 lookup filled the old packet pipe before a normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe received HUP and both a pending victim lookup and a later lookup failed with ENOENT in two out of two fresh-mount runs.

With this change, the new pipe remained active, received an intact 304-byte request, and both victim lookups completed in two out of two runs. Normal lookup and restart-without-a-blocked-writer controls passed. No KASAN, oops, refcount, or lock diagnostic was observed. A source reproducer and complete local logs are available privately on request.

The demonstrated impact is limited to denial of a shared autofs service during a legitimate daemon restart. No memory corruption, information leak, privilege escalation, or code execution primitive was observed.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/28/2026

This vulnerability resides within the automount filesystem implementation in the Linux kernel, specifically affecting the interaction between the kernel and user-space daemons responsible for managing mount points. The core issue is a race condition during the transition of notification pipes when an autofs daemon restarts or replaces its communication channel with the kernel. Under normal operation, the kernel sends notifications to a user-space process via a pipe file descriptor. When this daemon needs to restart, it typically enters a catatonic state and installs a new pipe for subsequent communications. The vulnerability arises because the function responsible for notifying the daemon, autofs_notify_daemon(), acquires a reference to the current notification pipe while holding the work queue mutex but then releases that mutex before attempting to write data into the pipe. This gap between releasing the lock and performing the I/O operation creates a window where the state of the system can change unexpectedly.

During this unlocked interval, it is possible for the daemon to enter catatonic mode again and install a replacement pipe while the kernel thread is still holding a reference to the old, now obsolete, pipe. If the reader end of that original old pipe is subsequently closed by user-space or other kernel logic, the delayed write operation initiated earlier will fail with an error code indicating a broken pipe, specifically -EPIPE. The generic error handling path within the autofs subsystem interprets this specific failure as a signal to enter catatonic mode itself. This creates a recursive and erroneous state transition where the kernel mistakenly believes it needs to restart its own daemon management cycle based on errors from an outdated communication channel rather than the current active one.

The operational impact of this flaw is primarily a denial of service for shared autofs services during legitimate daemon restarts. When triggered, the incorrect entry into catatonic mode causes the closure of the replacement pipe that was intended to handle new requests. Consequently, pending lookups and subsequent mount operations fail with ENOENT errors, effectively breaking access to filesystem resources managed by automount until a manual intervention or full service restart occurs. While this disrupts availability for users relying on dynamic mounting, it does not lead to memory corruption, information leakage, privilege escalation, or arbitrary code execution. The vulnerability is strictly limited to the logic flow of state management and pipe handling within the kernel's filesystem layer.

From a technical classification perspective, this issue aligns with CWE-362, which describes concurrent access race conditions that can lead to unexpected behavior due to improper synchronization. In terms of attack vectors, it relates to ATT&CK technique T1499, Endpoint Denial of Service, as the flaw allows an unprivileged user to disrupt service availability by triggering specific sequences of pipe closures during daemon restarts. The root cause is a classic time-of-check-to-time-of-use (TOCTOU) vulnerability where the state check regarding which pipe is current was not atomic with respect to the subsequent write operation and error handling logic.

The resolution involves refactoring the transition logic to ensure that the identity check of the notification pipe and the resulting state change are performed atomically while holding the necessary locks. By ensuring that only errors from the currently active pipe trigger a catatonic mode entry, the kernel avoids reacting to stale signals from replaced pipes. This fix prevents the erroneous closure of new replacement pipes during daemon restarts. System administrators should ensure their kernels are updated with this patch applied to maintain service continuity for environments relying on autofs for dynamic mount management. Monitoring logs for unexpected ENOENT errors or catatonic state transitions can help identify if systems have been affected by similar race conditions in unpatched versions.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/28/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!