Azure Linux 3.0 安全性更新核心 (CVE-2025-39989)
medium Nessus Plugin ID 295780
語言:
概要
遠端 Azure Linux 主機缺少一個或多個安全性更新。說明
遠端 Azure Linux 3.0 主機上安裝的核心版本比測試版舊。因此，此版本會受到 CVE-2025-39989 公告中提及的一個弱點影響。- 已解決 Linux 核心中的下列弱點：x86/mce: use is_copy_from_user() to determine copy-from-user context Patch series mm/hwpoison: Fix regressions in memory failure handling, v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a
-EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a (x86/futex: Remove .fixup usage) introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE May cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a real read and a speculative read.
So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af (mm/hwpoison: fix error page recovered but reported not ---truncated--- (CVE-2025-39989)
請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: Medium
ID: 295780
檔案名稱: azure_linux_CVE-2025-39989.nasl
版本: 1.1
類型: local
已發布: 2026/1/22
已更新: 2026/1/22
支援的感應器: Nessus
風險資訊
VPR
風險因素: Medium
分數: 4.4
CVSS v2
風險因素: Medium
基本分數: 4.6
時間性分數: 3.4
媒介: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C
CVSS 評分資料來源: CVE-2025-39989
CVSS v3
風險因素: Medium
基本分數: 5.5
時間性分數: 4.8
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
弱點資訊
CPE: p-cpe:/a:microsoft:azure_linux:kernel-debuginfo, p-cpe:/a:microsoft:azure_linux:kernel-devel, p-cpe:/a:microsoft:azure_linux:kernel-drivers-gpu, p-cpe:/a:microsoft:azure_linux:python3-perf, p-cpe:/a:microsoft:azure_linux:kernel-docs, x-cpe:/o:microsoft:azure_linux, p-cpe:/a:microsoft:azure_linux:kernel, p-cpe:/a:microsoft:azure_linux:kernel-drivers-sound, p-cpe:/a:microsoft:azure_linux:bpftool, p-cpe:/a:microsoft:azure_linux:kernel-drivers-intree-amdgpu, p-cpe:/a:microsoft:azure_linux:kernel-drivers-accessibility, p-cpe:/a:microsoft:azure_linux:kernel-tools
必要的 KB 項目: Host/local_checks_enabled, Host/AzureLinux/release, Host/AzureLinux/rpm-list, Host/cpu
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2025/7/8
弱點發布日期: 2025/4/18
參考資訊
CVE: CVE-2025-39989