Linux Distros 未修补的漏洞：CVE-2026-74686
critical Nessus 插件 ID 338911
语言：
简介
Linux/Unix 主机上安装的一个或多个程序包存在漏洞，但供应商表示不会修补此漏洞。描述
Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。- rqspinlock：死锁时保留队列时重置末尾 目前，在检测到死锁的情况下，rqspinlock 禁止破坏等候队列。死锁检查发生频率相对较高（AA 的输入时间，ABBA 的输入时间为 1 毫秒），涉及死锁的锁定场景可能不会涉及等待程序线程。因此，在我们检测到死锁并退出之后，不刷新队列并让其他等待程序尝试获取锁定非常有用。但是，我们需要遵循与之前对waitq_timeout标签相同的逻辑：重置尾巴，如果不能，则适当地向下一个服务员发出信号。发生死锁时，此信号仅将 MCS 节点标记为已解锁，而在超时时，此信号将发出RES_TIMEOUT_VAL信号。因此，差异在于传播的值，它决定了队列是保持活动状态还是被刷新。不进行尾部重置并等待下一个等待程序可导致我们是最后一个等待程序的情况，因此没有下一个等待程序到达，从而导致此路径中的间歇性停止。一旦下一位服务员加入，我们就会被解除阻断。在理论上，当下一个服务员永远不会加入时，我们就有可能无限期地拖延。这只会发生在 ABBA 死锁时，因为进入等待队列会受到 AA 检查保护。导致此情况的精确执行顺序可以是：CPU 0 保持锁定 A。CPU 1 保持锁定 B。CPU 2 尝试锁定 B，成为 B 的待定等待程序。CPU 0 尝试锁定 B。B 已设置锁定+挂起的位，因此 CPU 0 排队。CPU 1 尝试锁定 A。CPU 0 检测到 ABBA 死锁。CPU 0 发生死锁检测后，它将静坐等待队列中的下一个等待程序填充 node->next，这将遇到延迟，直到此类等待程序到达。通过调整 waitq_timeout 标签之前的死锁检查逻辑来修复此问题。合并这两种情况的代码并使用“ret”来区分传播的值是合理的，但这仅作为未来重构任务的练习，以避免此修补程序中出现 diff 噪声。（CVE-2026-74686）
请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。
解决方案
目前尚未有任何已知的解决方案。另见
插件详情
严重性: Critical
ID: 338911
文件名: unpatched_CVE_2026_74686.nasl
版本: 1.1
类型: Local
代理: unix
系列: Misc.
发布时间: 2026/8/22
最近更新时间: 2026/8/22
支持的传感器: Frictionless Assessment Agent, Nessus Agent, Agentless Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: Medium
分数: 5.8
百分位: 96.41
CVSS v2
风险因素: High
基本分数: 7.5
时间分数: 6.4
矢量: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS 分数来源: CVE-2026-74686
CVSS v3
风险因素: Critical
基本分数: 9.8
时间分数: 9
矢量: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
时间矢量: CVSS:3.0/E:U/RL:U/RC:C
漏洞信息
CPE: cpe:/o:debian:debian_linux:14.0, p-cpe:/a:debian:debian_linux:linux
必需的 KB 项: Host/local_checks_enabled, Host/cpu, global_settings/vendor_unpatched, Host/OS/identifier
易利用性: No known exploits are available
漏洞发布日期: 2026/8/22
参考资料信息
CVE: CVE-2026-74686