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

  - eventpoll: 在仍然持有 ep mutex 时，不要减少 ep 引用计数。Jann Horn 指出，epoll 会先减少 ep 引用计数，然后执行 mutex_unlock(&ep->mtx);。这种做法极为不妥，可能会导致释放后使用漏洞。但实际上，该模式对于最后一个引用是可行的，因为相关代码会将对 ep_free(ep) 的实际调用延迟到解锁 mutex。但是，对于更加微妙的倒数第二种情况而言，这种做法是错误的。在这种情况下，*其他人*也可能会在我们仍在使用 mutex 期间，放弃引用并释放 ep。请注意，即使其他用户也在使用同一个 ep mutex 也是如此: mutex 与 spinlock 不同，不能用来表示对象所有权，即使它们保证互斥也是如此。mutex 解锁操作不是原子操作，并且当一个用户仍在解锁期间访问 mutex 时，另一个用户可以进入并获得现已释放的 mutex，同时释放数据结构，而此时第一个用户仍在执行清理操作。请参阅 Documentation/locking/mutex-design.rst 中的 mutex 文件，重点关注第 [1] 节有关语义的部分:
    即使 mutex_unlock() 已在内部释放锁定，它仍可访问 mutex 结构，因此其他上下文无法安全获取该 mutex 并假设 mutex_unlock() 上下文不再使用该结构。如果我们在 mutex 解锁之前放弃 ep 引用，但我们不是最后一个引用者，则我们可以解锁 mutex，另一个用户进入、放弃 _their_ 引用并释放此时已无用户的“ep”——所有这一切都可以在 mutex_unlock() 仍然访问该文件期间进行。只需将 ep 引用计数放弃操作移动到 mutex 外部，即可修复此问题: 引用计数本身是原子操作，并且无需 mutex 保护 (这是引用计数的意义所在: 与 mutex 不同，它们本质上与对象生命周期有关)。
    (CVE-2025-38349)

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

检测

Linux Distros 未修补的漏洞：CVE-2025-38349

high Nessus 插件 ID 244743

版本 1.46