Azure Linux 3.0 安全性更新hyperv-daemons (CVE-2024-26939)
high Nessus Plugin ID 295850
語言:
概要
遠端 Azure Linux 主機缺少一個或多個安全性更新。說明
遠端 Azure Linux 3.0 主機上安裝的 hyperv-daemons 版本比測試版舊。因此，此版本會受到 CVE-2024-26939 公告中提及的一個弱點影響。- 已解決 Linux 核心中的下列弱點：drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ...
[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered
__intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129]
__gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from
__gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 (drm/i915: Remove the vma refcount) which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 (drm/i915/active: Fix missing debug object activation). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() May be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since
__i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace tile with GT across commit description (Rodrigo), -
---truncated--- (CVE-2024-26939)
請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 295850
檔案名稱: azure_linux_CVE-2024-26939.nasl
版本: 1.1
類型: local
已發布: 2026/1/22
已更新: 2026/1/22
支援的感應器: Nessus
風險資訊
VPR
風險因素: High
分數: 7.4
CVSS v2
風險因素: Medium
基本分數: 6
時間性分數: 4.4
媒介: CVSS2#AV:L/AC:H/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2024-26939
CVSS v3
風險因素: High
基本分數: 7
時間性分數: 6.1
媒介: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
弱點資訊
CPE: p-cpe:/a:microsoft:azure_linux:hypervvssd, p-cpe:/a:microsoft:azure_linux:hyperv-tools, p-cpe:/a:microsoft:azure_linux:hyperv-daemons-debuginfo, p-cpe:/a:microsoft:azure_linux:hyperv-daemons-license, x-cpe:/o:microsoft:azure_linux, p-cpe:/a:microsoft:azure_linux:hypervfcopyd, p-cpe:/a:microsoft:azure_linux:hypervkvpd, p-cpe:/a:microsoft:azure_linux:hyperv-daemons
必要的 KB 項目: Host/local_checks_enabled, Host/AzureLinux/release, Host/AzureLinux/rpm-list, Host/cpu
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2025/4/8
弱點發布日期: 2024/5/1
參考資訊
CVE: CVE-2024-26939