CVE-2026-99181: autofs: ignore notification errors from a replaced pipe

Published Oct 28, 2026
·
Updated

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

autofs: ignore notification errors from a replaced pipe

autofsnotifydaemon() takes a reference to the current notification pipe under wqmutex, 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 Software

1 affected component
Linux Linux kernel=v7.3-rc5-337-gff47652a4b66c

Event History

Oct 28, 2026
CVE Published
via MITRE·10:35 AM
Data Sourced
via MITRE·10:35 AM
Description
Data Sourced
via NVD·11:17 AM
Description

Frequently Asked Questions

1

What conditions are needed to trigger the failure?

A notification write to the old autofs pipe must block while the daemon enters catatonic mode and installs a replacement pipe. If the old pipe reader is then closed, the delayed write can return EPIPE; the reported reproduction filled the old packet pipe with an unprivileged lookup before a CATATONIC/SETPIPEFD restart.

2

What is the practical impact of a successful trigger?

The erroneous catatonic transition can close the replacement pipe and release the new daemon generation's wait queues. In the reported test, the new pipe received HUP and both a pending lookup and a later lookup failed with ENOENT.

3

How can administrators recognize that this condition has occurred?

The described symptom is a HUP on a newly installed autofs notification pipe after a daemon restart, accompanied by failed pending or subsequent lookups returning ENOENT. The issue specifically involves replacement of the notification pipe while a write to the prior pipe is delayed.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203