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

  - x86/mce使用 is_copy_from_user() 确定复制自用户上下文 修补程序系列 mm/hwpoison修复内存故障处理 v4 中的回归。 ## 1. 我要实现的目标与 5.10 LTS 相比此修补程序集解决自版本 5.17以来上游内核中出现的两个与内存故障处理相关的危急回归。 - copyin 案例从用户空间进行内核复制时在用户页面中发现毒 - instr 案例在用户空间中提取指令时发现毒 ## 2. 预期结果是什么以及原因 - 对于 copyin 案例内核可从其中发现的毒中恢复如果内核正在执行 get_user() 或 copy_from_user() 这些位置获得错误返回并且内核将 -EFAULT 返回给进程而不是崩溃。更具体地说MCE 处理程序会检查修复处理程序类型以确定是否可以恢复内核 #MC。当发现 EX_TYPE_UACCESS 时PC 会跳转到 中指定的恢复代码
    _ASM_EXTABLE_FAULT() 并向用户空间返回 -EFAULT。- 对于指令情况如果在用户空间中提取指令时发现中毒则可以完全恢复。用户进程占用 #PFLinux 会通过读取存储空间来分配新页面并进行填充## 3. 实际发生的情况及原因 - 对于 copyin 案例自 v5.17 起的内核错误 Commit 4c132d1d844a (x86/futex删除 .fixup 使用) 引入了新的可扩展修复类型 EX_TYPE_EFAULT_REG且更高的修补程序更新了 的可扩展修复类型copy-from-user 操作从而将其从 EX_TYPE_UACCESS 更改为 EX_TYPE_EFAULT_REG。在 get_user() 或 copy_from_user() 中发现 position 时它会中断之前的 EX_TYPE_UACCESS 处理。- 对于 instr 情况由于 #CMCI 和 #MCE 争用用户进程被 SIGBUS 信号终止。消耗了未修正的内存错误时来自报告具有 UCNA 签名的未修正错误的内存控制器的 CMCI 与即将使用数据时的核心报告和 SRAR 签名计算机检查。 ### 背景原因
    在低于 Icelake 的内存控制器报告的巡检 scrub 事件中*UN*corrected 修正 Intel 平台 [1] 中的 *C*MCI 相关错误通过发出广播广播计算机检查信号与 SRAO软件可恢复操作可选检测到内存中先前未见的未修正错误机器检查银行中的签名。
    这是多余的因为没有核心处于消耗这种不良数据的边缘这不是一个紧迫的问题。还发现多个 SRAO UCE 可能会造成嵌套的 MCE 中断并最终变成 IERR。
    因此Intel 将 patches 的计算机检查组签名从 SRAO 降级为 UCNA未更正，无需操作并将信号更改为 #CMCI。更令人困惑的是Linux 确实在 uc_decode_notifier() 中采取一个操作尝试使页面脱机尽管有 UC*NA* 签名名称。 ### 背景
    当中毒在 Intel 平台中消耗时为什么 #CMCI 和 #MCE 会争用 [1] 在确定 CMCI/UCNA 是巡视 scrub 错误的最佳操作后内存控制器也会使用该操作进行读取。但是内存控制器从 核心异步执行无法区分真正的读取和推测的读取。因此如果在任何读取中发现错误 系统将会执行 CMCI/UCNA。因此：1) Core 认为很明智，认为很快需要地址 A，从而发出推测读取请求。 2) 核心发现其在发送读取请求后不久将使用地址 A。 3) 内存控制器的 CMCI 与核心的 MCE 争用很快将尝试从地址 A 引退负载。非常频繁因为推测已改善将核心提交到指令读取地址 A 之前提交内存控制器的 CMCI因此发生中断Linux 使该页面脱机将其标记为中毒。 ## 为什么会因 instr case Commit 046545a661af 终止用户进程 (mm/hwpoison修复页面已恢复但未报告错误 ---truncated--- (CVE-2025-39989)

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

检测

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

medium Nessus 插件 ID 244032

未找到变更日志