Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - fsnotify：修复并发标记更新后过时的对象掩码 当标记获得新的事件位时，如果缓存的聚合已包含该位，则 fanotify 和 inotify 可避免重新计算该对象掩码。
    这与对同一连接器上另一个标记的并发更新触发的重新计算是争用的。
    并发扫描可以在添加新位之前读取标记，而更新程序会在扫描发布其结果之前读取旧聚合。然后，更新程序会跳过重新计算，扫描会发布一个没有该位的掩码，这样在两次更新都完成后会使对象掩码过时。这可以通过两个监视同一个 inode 的 fanotify 组来重现：一个线程从一个现有标记中删除FAN_MODIFY，而另一个线程向另一个标记添加FAN_MODIFY。在两个 fanotify_mark（） 调用返回后，写入可能无法为标记现在包含该位的群组生成FAN_MODIFY。这在未修改的 v6.12.95 内核中重现。等效的 inotify 交错会丢失IN_MODIFY事件。
    对于普通 fanotify 添加，请在原始标记掩码变更时重新计算。法线掩码不会以异步方式清除，因此未更改的添加无法导致缺失兴趣。始终重新计算 ignore-mask 更新，因为FS_MODIFY处理可能会清除忽略掩码而不进行 mark->lock，从而使快照比较不可靠。更新现有 inotify 监视目录后始终重新计算。其替换路径临时将 mark->mask 设置为零，因此即使旧掩码和最终掩码相等，并发扫描也可观察到零。直接分配替换掩码可避免暂时性零，但现有监视更新并不频繁，因此无条件重新计算更简单。（CVE-2026-89595）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-89595

medium Nessus 插件 ID 345289

版本 1.8