Cloudanix VulnDB

CVE-2026-99181

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can make automatic file-system mounting stop working correctly when its management program restarts, briefly breaking file access for users.

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

Race condition in autofs_notify_daemon allows a blocked write to an old notification pipe to incorrectly trigger catatonic mode on a replacement pipe, causing subsequent lookups to fail with ENOENT.

Why it matters to the business

Shared autofs mounts can become unavailable during normal daemon restarts, interrupting file access for users and applications that depend on on-demand mounting.

How an attack unfolds

An unprivileged process fills the current autofs notification pipe; when the daemon restarts and installs a new pipe, the delayed write on the old pipe returns an error that erroneously shuts down the new pipe and its wait queues, blocking legitimate mount requests.

How to fix it

Apply the upstream kernel fix that adds an identity check before entering catatonic mode so the transition is atomic with pipe replacement; rebuild and deploy the patched kernel on affected systems.

How to confirm the fix worked

Confirm the presence of the atomic identity check and locked transition in autofs_notify_daemon; reproduce the original reproducer scenario and verify that victim lookups succeed after a blocked-writer restart.

Typical attack path

  1. Fill the active autofs packet pipe with requests from an unprivileged UID
  2. Trigger a CATATONIC/SETPIPEFD restart sequence in the autofs daemon
  3. Cause the delayed -EPIPE error path to act on the now-replaced pipe
  4. Observe ENOENT failures on subsequent lookup operations

How to detect it

Review kernel and autofs daemon logs for sequences of pipe replacement events followed by ENOENT lookup failures; correlate with process activity that writes many requests to autofs control pipes.

What your security team should do

  • Prioritize patching autofs-enabled kernels as soon as the fix is available in distribution updates
  • Monitor for autofs daemon restarts coinciding with lookup failures in system logs
  • Consider temporary workarounds such as increasing pipe buffer sizes or reducing concurrent mount activity during maintenance windows

The record

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.

Affected packages

Ecosystem Package Introduced Fixed