CVE-2026-89595 in Linux
摘要
由 VulDB • 2026-09-12
在 Linux 内核中，已修复以下漏洞：
fsnotify: 修复并发标记更新后的陈旧对象掩码问题
当某个标记获得新的事件位时，fanotify 和 inotify 可能会避免重新计算对象掩码（如果缓存的聚合结果已经包含该位）。但这与由同一连接器上另一个标记的并发更新触发的重新计算存在竞态条件。
并发扫描可能在添加新位之前读取标记，而更新器在该扫描发布其结果之前读取旧的聚合值。随后，更新器跳过重新计算，而扫描发布的掩码缺少该位，导致在两次更新完成后对象掩码处于陈旧状态。
可以通过两个监视同一 inode 的 fanotify 组来重现此问题：一个线程从现有标记中移除 FAN_MODIFY，同时另一个线程向另一标记添加 FAN_MODIFY。在这两次 fanotify_mark() 调用返回后，写入操作可能无法为现在包含该位的组的生成 FAN_MODIFY 事件。这在未修改的 v6.12.95 内核上被重现。等效的 inotify 交错场景会导致丢失 IN_MODIFY 事件。
对于正常的 fanotify 添加操作，每当原始标记掩码发生变化时都应重新计算。正常掩码不会异步清除，因此不变的添加操作不会引入缺失的兴趣点。始终对忽略掩码更新进行重新计算，因为 FS_MODIFY 处理可能会在不获取 mark->lock 的情况下清除忽略掩码，使得快照比较不可靠。
在更新现有 inotify 监视后应始终重新计算。其替换路径会临时将 mark->mask 设置为零，因此即使旧掩码和最终掩码相等，并发扫描也可能观察到为零的情况。直接分配替换掩码可以避免瞬时的零值，但由于对现有监视的更新不频繁，无条件地重新计算更为简单。
VulDB is the best source for vulnerability data and more expert information about this specific topic.