CVE-2026-89595

What it actually does

A race in the Linux kernel fsnotify connector path can leave an inode’s aggregated object mask stale after concurrent fanotify or inotify mark updates. When one mark gains an event bit (notably FAN_MODIFY / IN_MODIFY) while another mark on the same object is updated, a concurrent mask recalculation can publish a mask that omits the new bit. The kernel then fails to generate the corresponding filesystem notification events even though a live mark still requests them. This is a correctness/race defect in event delivery, not memory corruption, privilege escalation, or remote code execution.

Why it matters to the business

File integrity monitoring, audit, EDR, backup, and application watchers that rely on inotify or fanotify can silently miss file modifications, creating compliance and detection gaps rather than outages. Likelihood of active abuse is low: EPSS is about 0.002 and unchanged over 30 days, exploit maturity is none, the CVE is not in CISA KEV, and it is not associated with ransomware. The issue has been public for roughly 37 days. Urgency is highest on Linux hosts where fsnotify is a primary control for change detection; it is lower where integrity is enforced by independent hashing, mandatory access control, or remote telemetry.

How an attack unfolds

Abuse is local and opportunistic, aimed at evading watchers rather than taking over the host. An attacker who can cause overlapping mark add/remove/replace operations on an inode that is also watched by a security or backup agent may induce the stale-mask window described in the fix. After both mark updates return, writes to that inode may not produce FAN_MODIFY or IN_MODIFY for the group that still holds the bit, so file-integrity or audit pipelines never see the change. Typical fanotify administration needs elevated capability, while inotify watches are often creatable by unprivileged processes; either path only yields missed events, not kernel code execution. No named threat actors, public exploits, or KEV/ransomware use are indicated.

How to fix it

Apply the vendor or upstream Linux kernel update that contains the fsnotify fix for stale object masks after concurrent mark updates (always recalculate on normal fanotify mask changes and ignore-mask updates, and after existing inotify watch updates). Rebuild or refresh distribution kernels, android/oem kernels, and any out-of-tree images from a release whose changelog includes this fsnotify resolution. Until patched, do not treat inotify/fanotify as the sole file-integrity control; complement with periodic hashing, remote backup comparison, or LSM policy. Avoid unnecessary concurrent fanotify_mark/inotify watch churn on the same inodes in security agents.

How to confirm the fix worked

Confirm the running kernel (uname and distro package changelog) includes the fsnotify stale-object-mask fix; unpatched v6.12.95-class trees are known to be affected. After upgrade, exercise concurrent mark updates on a test inode with two fanotify groups (add vs remove FAN_MODIFY) and with inotify watch replacement, then verify subsequent writes still generate events for every group whose mark includes the bit. Inventory production FIM/EDR/backup agents that call fanotify or inotify and confirm they receive modify events under concurrent watch updates. Hosts still on kernels without the fix should be treated as exposed.

Typical attack path

1. Gain local ability to create or update inotify/fanotify marks on an inode already watched by a monitoring agent
2. Overlap a mark update that adds modify-interest with a concurrent mark change on the same connector
3. After both updates complete, modify the watched file or directory
4. Rely on the stale object mask so the legitimate watcher does not receive FAN_MODIFY/IN_MODIFY
5. Continue follow-on file tampering while integrity or audit tooling reports no change

How to detect it

Successful abuse leaves few artifacts because the failure mode is omitted events, not a crash or new process. Hunt retrospectively on unpatched kernels for gaps where file mtime/content changed but fanotify/inotify-based FIM, audit, or backup pipelines recorded no corresponding modify event, especially around concurrent watch updates. Useful sources: kernel and distro package versions; audit of fanotify_mark and inotify add/modify syscalls; EDR/FIM agent logs showing watch registration without a later modify event; application logs from backup or IDE watchers. Correlate with two or more watchers on the same inode. Absence of public exploits and named actors means there are no campaign-specific signatures; treat missing modify events plus an unpatched kernel as the primary indicator, not a unique malware family.

What your security team should do

• Patch Linux kernels to a build that includes the fsnotify concurrent-mark mask recalculation fix; prioritize fleets whose FIM, EDR, or backup path depends on fanotify/inotify
• Until patched, add a compensating integrity check (scheduled hashes, remote backup diff, or host-based policy) so missed FAN_MODIFY/IN_MODIFY cannot be the only signal
• Inventory local processes with fanotify (typically privileged) or heavy inotify watch usage and reduce concurrent mark add/remove on shared inodes in security agents
• Track this CVE as low likelihood (flat ~0.002 EPSS, not KEV, no known exploit) but do not ignore it on monitoring-critical Linux estates
• After patching, regression-test modify-event delivery under concurrent mark updates before closing the finding