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

  - af_unix如果 MSG_PEEK 干预则放弃 GC。Igor Ushakov 报告 GC 因与 MSG_PEEK 的争用而清除了活动套接字的接收队列并获得了良好的重现。此问题与之前由 提交 cbcf01128d0aaf_unix 修复的问题完全相同此问题修复垃圾与 MSG_PEEK 的收集。将 GC 替换为当前算法之后引用的提交删除了 unix_peek_fds() 中的锁之交并重新引入了相同的问题。问题在于 MSG_PEEK 会在未与 GC 交互的情况下增加文件引用计数。考虑包含 sk-A 和 sk-B 的 SCC其中 sk-A 可 close()d 但可通过 sk-B 进行 recv()ed。如果 sk-A 通过 MSG_PEEK 从 sk-B 进行 recv()ed 并且在 GC 检查 sk-A 和 sk-B 的 unix_vertex_dead() 时对 sk-B 进行 close()d则会发生此问题。GC 线程 用户线程 --------- ----------- unix_vertex_dead(sk-A) -> true <------。 \ `------ recv(sk-B, MSG_PEEK) 无效!! -> sk-A 的文件引用计数 1 -> 2 close(sk-B) -> sk-B 的文件引用计数 2 -> 1 unix_vertex_dead(sk-B) -> true 最初sk-A 的文件引用计数为 1 sk-B recvq 中的 inflight fd。GC 认为 sk-A 已死因为文件引用计数与其 inflight fd 的数量相同。但是sk-A 的文件引用计数会被 MSG_PEEK 静默增加从而使之前的评估无效。此时sk-B 的 file refcount 为 2一个由 open fd 触发另一个由 sk-A 中的 inflight fd 触发。后续的 close() 通过前者释放一个引用计数。最后GC 错误地断定 sk-A 和 sk-B 都已死机。一个选项是恢复 unix_peek_fds() 中的锁定之差但感谢新算法我们可以更妥善地解决此问题。关键是如果不使用后续的 close()则不会发生此问题而且我们实际上不需要将 MSG_PEEK 与无效的 SCC 检测同步。发生 问题时close() 和 GC 会接触同一个文件引用计数。如果 GC 发现 refcount 因 close() 而递减则它可能只是放弃对 SCC 进行垃圾回收。因此，我们只需在 MSG_PEEK 期间使用适当的内存屏障发出争用信号即可对 GC 可见。让我们使用 seqcount_t 在发生 MSG_PEEK 时通知 GC 并将 SCC 推迟到下一次运行。这样就不需要在 MSG_PEEK 侧上锁定我们可以避免对每个 MSG_PEEK 施加不必要的损失。请注意如果检测到 MSG_PEEK则可在 unix_scc_dead() 内重试但这样做是为了避免因滥用 MSG_PEEK 调用而导致挂起任务 splat。 (CVE-2026-23394)

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

检测

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

medium Nessus 插件 ID 303674

版本 1.4