CVE-2026-46040: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails
In the Linux kernel, the following vulnerability has been resolved:
inotify: fix watch count leak when fsnotifyaddinodemarklocked() fails
When fsnotifyaddinodemarklocked() fails in inotifynewwatch(), the error path calls inotifyremovefromidr() but does not call decinotifywatches() to undo the preceding incinotifywatches(). This leaks a watch count, and repeated failures can exhaust the maxuserwatches limit with -ENOSPC even when no watches are active.
Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotifyaddmarklocked() succeeded, so this path was not affected. The conversion moved incinotifywatches() before the mark insertion without adding the corresponding rollback.
Add the missing decinotifywatches() call in the error path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.141.1-1 - Upgrade
Upgrade
Linux kernel inotify: fix watch count leak when fsnotify_add_inode_mark_locked() failsto a version that resolves this vulnerability.Patch 1cce1eea0aff
Event History
Frequently Asked Questions
What conditions are needed to trigger the resource exhaustion?
An attacker needs local access and the ability to create inotify watches. They must repeatedly cause fsnotify_add_inode_mark_locked() to fail; each failed attempt can leak a watch count.
What is the practical impact of repeated failed watch creations?
The leaked counts can exhaust the max_user_watches limit, causing subsequent watch creation attempts to fail with -ENOSPC even when no inotify watches are active. The provided data indicates availability impact only, with no confidentiality or integrity impact.
Are all affected kernel generations exposed to this error path?
No. The description states that kernels before commit 1cce1eea0aff were not affected because the watch count was incremented only after successful mark insertion. The affected behavior was introduced when the code was converted to per-namespace limits.
How can administrators recognize that this issue may already be occurring?
Affected systems may return -ENOSPC when creating inotify watches despite having no active watches. This can occur after repeated failures in the inode-mark insertion path have accumulated leaked watch counts.