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

  - arm64/entrycpu_switch_to()、call_on_irq_stack() `cpu_switch_to()` 和 `call_on_irq_stack()` 中的掩码 DAIF 操纵 SP 更改为不同的堆栈以及影子调用堆栈如果启用。这两个堆栈变更无法自动完成且两个函数均可被 SError 或 Debug Exception 中断尽管不太可能但已造成很大的破坏 如果被中断我们将以不匹配的堆栈和导致堆栈损坏的影子调用堆栈告终。在“cpu_switch_to()”中当 SP_EL0 指向新任务但 x18 仍然指向旧任务的 SCS 时会发生此问题。当中断处理程序尝试保存任务的 SCS 指针时会将旧的任务 SCS 指针 (x18) 保存到新的任务结构由 SP_EL0 指向中从而对其进行重写。在“call_on_irq_stack()”中在任务堆栈和 IRQ 堆栈之间来回切换时可能发生这种情况。在这两种情况下当 SCS 指针指向 IRQ SCS但 SP 指向任务堆栈时我们会遭到中断。嵌套的中断处理程序将其返回地址推送到 IRQ SCS。然后它会检测到 SP 指向任务堆栈、调用“call_on_irq_stack()”并使用 IRQ SCS 指针破坏任务 SCS 指针它也将使用该指针这会导致任务返回到错误 SCS甚至 IRQ SCS 上的地址通过 CONFIG_VMAP_STACK 或 FPAC如果启用触发内核错误。这在默认配置中是可能的，但不太可能。但是，在启用 CONFIG_ARM64_PSEUDO_NMI 时，系统会取消屏蔽 DAIF，取而代之的是由 GIC 负责根据优先级筛选 CPU 应接收的中断。考虑到仿真 NMI 的目标即使在“cpu_switch_to()”和“call_on_irq_stack()”中CPU 也可接收伪 NMI根据系统配置和工作负载可能*非常*频繁地接收从而导致不可预测的内核错误。完全屏蔽“cpu_switch_to()”中的 DAIF 并在返回时将其还原。在“call_on_irq_stack()”中执行相同操作但还原 并屏蔽 分支。即使未启用 CONFIG_SHADOW_CALL_STACK 也要掩码 DAIF以保证所有配置之间的行为一致性。引入并使用汇编宏来保存和屏蔽 DAIF因为现有宏会保存但仅屏蔽 IF。 (CVE-2025-38670)

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

检测

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

high Nessus 插件 ID 260270

版本 1.7

版本 1.6

版本 1.3

版本 1.7 Oct 29, 2025, 3:03 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202510290303
版本 1.6 Oct 28, 2025, 5:56 PM Detection (updated detection logic) Plugin Feed: 202510281756
版本 1.3 Sep 25, 2025, 11:29 PM CVSS metrics ("CVSSv2 score" set to 5.6) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:H/Au:N/C:N/I:C/A:C") Detection (updated detection logic) Plugin metadata Plugin Feed: 202509252329