CVE-2026-89595
Received Received - Intake

Race Condition in Linux Kernel fsnotify Leading to Stale Object Mask

Vulnerability report for CVE-2026-89595, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-09-11

Last updated on: 2026-09-11

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-11
Last Modified
2026-09-11
Generated
2026-09-12
AI Q&A
2026-09-12
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.12.95

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a race condition in the Linux kernel's filesystem notification system (fsnotify). It occurs when two threads update event marks on the same file concurrently. One thread may fail to recalculate the object's event mask properly, causing the system to miss important events like file modifications. This affects both fanotify and inotify mechanisms.

Detection Guidance

This vulnerability is specific to the Linux kernel's fsnotify subsystem and requires kernel-level inspection. Detection involves checking kernel logs for fsnotify-related errors or verifying the kernel version against patched versions. No direct commands are provided in the context to detect this issue.

Impact Analysis

If exploited, this flaw could cause applications monitoring file changes to miss critical events. For example, security tools relying on fanotify might fail to detect unauthorized file modifications, or backup software could miss files that were modified. This could lead to data loss or security breaches going unnoticed.

Mitigation Strategies

Apply the latest kernel patches that resolve this issue. Monitor kernel updates from your Linux distribution and upgrade to a patched version. No workaround is mentioned in the provided context.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-89595. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart