CVE-2026-46040

What it actually does

This is a local denial-of-service flaw in the Linux kernel inotify subsystem. When creation of a new inotify watch fails inside fsnotify_add_inode_mark_locked(), the kernel removes the watch from its ID tracking structure but fails to decrement the previously incremented per-user or per-namespace inotify watch counter. Repeatedly triggering this failure leaks watch-count quota without leaving active watches behind. Over time, the affected user or namespace can hit max_user_watches and receive ENOSPC errors for new inotify watches, breaking software that depends on filesystem event monitoring. The flaw does not provide code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

A low-privileged local user or process can make file-watching functionality unreliable on affected Linux systems. This can disrupt developer tooling, file synchronization agents, monitoring agents, security tools, application reload mechanisms, container workloads, and services that rely on inotify. The likely business impact is operational degradation or outage on shared Linux hosts, CI/CD runners, developer workstations, container nodes, or multi-user systems rather than data theft. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so remediation should be prioritized as routine kernel maintenance unless the system is multi-tenant or highly dependent on inotify-based services.

How an attack unfolds

An attacker first needs local execution as an unprivileged user or inside a context that can call inotify APIs. The attacker repeatedly invokes inotify watch creation in a way that causes the kernel mark insertion step to fail after the inotify watch counter has already been incremented. Because the vulnerable error path does not roll the counter back, each failed attempt consumes part of the user or namespace inotify watch quota even though no corresponding active watch remains. After enough repetitions, the quota reaches fs.inotify.max_user_watches. Legitimate applications running under the same affected user or namespace then fail to create new watches and receive ENOSPC or "No space left on device" style errors, causing degraded monitoring, missed file-change events, application failures, or service instability.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the inotify fix adding the missing dec_inotify_watches() rollback on the fsnotify_add_inode_mark_locked() failure path. Because no exact fixed package versions were provided, track vendor advisories for the affected kernel branch and upgrade to the first kernel build that explicitly references this inotify watch-count leak fix or the corresponding upstream patch. Reboot into the fixed kernel after installation; merely installing kernel packages is insufficient if the system continues running the vulnerable kernel. As temporary mitigation, restrict untrusted local shell access, reduce opportunities for untrusted workloads to run in shared user or namespace contexts, isolate containers and users that can consume inotify quotas, monitor and tune fs.inotify.max_user_watches carefully, and restart affected workloads or namespaces if leaked counters cause persistent ENOSPC conditions. Increasing max_user_watches may reduce symptoms but does not fix the leak and can allow more resource consumption.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor build containing the inotify rollback fix. Validate with uname -a, package manager kernel version output, and vendor advisory or changelog references to the inotify watch count leak fix. In a non-production test system, attempt to reproduce the failure condition and verify that failed inotify_add_watch operations no longer consume max_user_watches quota. Operationally, confirm that applications can create inotify watches normally and that ENOSPC or "No space left on device" errors related to file watching stop after patching and rebooting. Review /proc/sys/fs/inotify/max_user_watches and active inotify usage through /proc/<pid>/fdinfo where appropriate to ensure apparent quota exhaustion matches real active watches rather than leaked counts.

Typical attack path

1. Gain local code execution as an unprivileged user, compromised application account, container workload, or interactive shell on an affected Linux kernel.
2. Create an inotify instance and repeatedly attempt to add watches under conditions that cause fsnotify_add_inode_mark_locked() to fail.
3. Abuse the vulnerable error path so each failed watch creation increments but does not decrement the inotify watch counter.
4. Continue until the affected user or namespace reaches the configured max_user_watches limit.
5. Cause legitimate processes relying on inotify to fail when they attempt to register new filesystem watches.
6. Maintain or repeat the activity to keep file-watching functionality degraded until the system is patched, limits are reset, or the affected namespace/session is remediated.

How to detect it

Look for evidence of abnormal inotify watch allocation failures and quota exhaustion. Useful sources include application logs, systemd journal, auditd syscall records if inotify_add_watch auditing is enabled, eBPF/syscall telemetry, endpoint process telemetry, and container runtime logs. Linux does not normally log every failed inotify_add_watch call by default, so absence of logs does not prove absence of exploitation. Investigate repeated ENOSPC or "No space left on device" errors from applications that use file watchers, especially when /proc/<pid>/fdinfo shows relatively few active inotify watches compared with the exhausted max_user_watches limit. Correlate failures by user, namespace, container, process name, and time window. Suspicious behavior includes a single low-privileged process generating a high rate of failed inotify_add_watch calls, repeated creation and disposal of inotify file descriptors, or watch-limit exhaustion without a corresponding number of active watches. Because this vulnerability leaves quota state rather than a durable file artifact, forensic confirmation may require live telemetry, audit/eBPF traces, or reproducing the mismatch between apparent quota exhaustion and active watches before reboot or namespace cleanup.

• inotify_add_watch
• ENOSPC
• No space left on device
• System limit for number of file watchers reached
• User limit of inotify watches reached
• fs.inotify.max_user_watches
• /proc/sys/fs/inotify/max_user_watches
• /proc/*/fdinfo/*
• audit:.*inotify_add_watch.*exit=-28
• inotify watch limit reached
• Failed to add watch
• Too many open files in system

What your security team should do

• Inventory Linux systems and container hosts running kernels in affected branches, especially shared servers, developer platforms, CI/CD runners, Kubernetes nodes, and multi-tenant systems.
• Prioritize patching systems where untrusted users, build jobs, plugins, containers, or application code can execute local processes.
• Apply vendor kernel updates that include the inotify fix and reboot systems into the fixed kernel.
• Monitor for bursts of failed inotify_add_watch activity, ENOSPC errors, and application logs indicating exhausted file watcher limits.
• Do not rely on increasing fs.inotify.max_user_watches as a permanent fix; use it only as a short-term operational workaround if needed.
• Restrict or isolate untrusted local workloads until patching is complete, particularly where multiple services share the same user, namespace, or host-level resource limits.
• After remediation, verify the running kernel version and check that services dependent on inotify have recovered without recurring watch-limit errors.