The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest     under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped     as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM     are enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory     descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a     SystemMemory entry is present, then the kernel's ACPI driver will auto-ioremap the region so that it can     be accessed at will. However, the ACPI spec doesn't provide a way to enumerate the memory type of     SystemMemory regions, i.e. there's no way to tell software that a region must be mapped as UC vs. WB, etc.
    As a result, Linux's ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on     x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their     associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bare metal and non-     CoCO, the conflicting requirements work as firmware configures the PCI hole (and other device memory) to     be UC in the MTRRs. So even though the ACPI mappings request WB, they are forced to UC- in the kernel's     tracking due to the kernel properly handling the MTRR overrides, and thus are compatible with the drivers'     requested WC/UC-. With force WB MTRRs on SNP and TDX guests, the ACPI mappings get their requested WB if     the ACPI mappings are established before the dedicated driver code attempts to initialize the device. E.g.
    if acpi_init() runs before the corresponding device driver is probed, ACPI's WB mapping will win, and     result in the driver's ioremap() failing because the existing WB mapping isn't compatible with the     requested WC/UC-. E.g. when a TPM is emulated by the hypervisor (ignoring the security implications of     relying on what is allegedly an untrusted entity to store measurements), the TPM driver will request UC     and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis     MSFT0101:00: probe with driver tpm_tis failed with error -12 Note, the '0x2' and '0x0' values refer to     enum page_cache_mode, not x86's memtypes (which frustratingly are an almost pure inversion; 2 == WB, 0     == UC). E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU:
    22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0     PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google     Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460
    __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20     acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440     acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530     acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0     acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530     acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190     acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600     acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490     acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0     acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360     acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0     do_one_i ---truncated--- (CVE-2025-40181)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - x86/kvmTDX/SNP の MTRR をオーバーライドする際、レガシー PCI ホールを UC に強制します。KVM のもとで SNP または TDX ゲストとして実行する際、レガシー PCI ホール、すなわち Top of Low Useable DRAM と 4GiB の間のメモリを強制的にマッピングします。強制された変数 MTRR 範囲を介した UC 。ほとんどの KVM ベースのセットアップでは、HPET や TPM などのレガシーデバイスは ACPI を介して列挙されます。ACPI 列挙には、Memory32Fixed エントリが含まれ、オプションで OperationRegion 用の SystemMemory 記述子が含まれます (たとえばコントロールメソッドを介してアクセスする必要がある場合)。SystemMemory エントリが存在する場合、カーネルの ACPI ドライバーが領域を自動 ioremap して、意図にアクセスできるようにします。ただし、ACPI 仕様では、SystemMemory 領域のメモリタイプを列挙する方法は提供されません。つまり、領域を UC 対 としてマッピングする必要があることをソフトウェアに通知する方法がありません。WB など
    その結果、LinuxのACPIドライバーは常に、ioremap_cache()を使用して、つまりx86上のWBとしてSystemMemory領域をマップします。しかし、HPETドライバーやTPMドライバーなどの専用デバイスドライバーは、WBを使用したPCIデバイスへのアクセスがサポートされていないため、関連メモリをUCまたはWCとしてマッピングする必要があります。ベアメタおよび非 CoCO では、ファームウェアが PCI ホールおよび他のデバイスメモリを MTRR の UC になるように構成する際に、競合する要件が機能します。そのため、ACPI マッピングが WB をリクエストしても、カーネルが MTRR オーバーライドを適切に処理するため、カーネルの追跡で UC- に強制され、ドライバーがリクエストした WC/UC- と互換性があります。SNP および TDX ゲストに強制 WB MTRR を適用すると、専用ドライバーコードがデバイスの初期化を試行する前に ACPI マッピングが確立されると、ACPI マッピングはリクエストされた WB を取得します。例：
    対応するデバイスドライバーがプローブされる前に acpi_init() が実行されると、ACPI の WB マッピングが成功し、既存の WB マッピングがリクエストされた WC/UC- と互換性がないため、ドライバーの ioremap() が失敗します。たとえば、TPM がハイパーバイザーによってエミュレートされるとき (測定を保存するために、信頼できないエンティティと思われるものに依存するセキュリティ上の影響を無視する)、TPM ドライバーは UC をリクエストして失敗します。[ 1.730459] 0xfed40000-0xfed45000 の ioremap エラー、0x2 がリクエストされました。 、 が 0x0 を取得しました 1.732780] tpm_tis MSFT0101:00ドライバー tpm_tis を使ったプローブが、エラー -12 で失敗しました注意「0x2」および「0x0」の値は、x86 の memtype ではなく、enum page_cache_mode を参照しています原因不明なために、ほぼ純粋な反転2 == WB、0 == UC。たとえば、TPM TIS のマッピングリクエストをトレースすると、以下が発生しますreq_type = 0 で TPM TIS をマッピングします警告CPU
    22 PID1 at arch/x86/mm/pat/memtype.c530 memtype_reserve+0x2ab/0x460 モジュールがリンクされていますCPU22 UID0 PID1 通信swapper/0 汚染済みGW 6.16.0-rc7+ #2 VOLUNTARY 汚染: [W]=WARN ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460
    __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i ---truncated---CVE-2025-40181

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - x86/kvm覆寫 TDX/SNP 的 MTRR 時在 UC 中有舊版 PCI 漏洞。在 KVM 下作為 SNP 或 TDX 來賓執行時強制將舊版 PCI 漏洞 (即可用 DRAM 下層頂端和 4GiB 之間的記憶體) 對應為透過強制變數 MTRR 範圍的 UC。在大多數 KVM 型設定中HPET 和 TPM 等舊版裝置是透過 ACPI 列舉。ACPI 列舉包含 Memory32Fixed 項目以及 OperationRegion 的選擇性 SystemMemory 描述符號例如在裝置需要透過控制方法存取的情況下。如果存在 SystemMemory 項目則核心的 ACPI 驅動程式會自動 ioremap 區域以供任意存取。不過ACPI 規格並未提供列舉 SystemMemory 區域記憶體類型的方法亦即無法告知軟體某個區域必須對應為 UC 與WB 等
    因此Linux 的 ACPI 驅動程式一律使用 ioremap_cache() 對應 SystemMemory 區域例如 x86 上的 WB。不過由於不支援使用 WB 存取 PCI 裝置專用裝置驅動程式 (例如 HPET 驅動程式和 TPM 驅動程式) 想要將其相關聯的記憶體對應為 UC 或 WC。在實體機和非 CoCO 上當韌體將 PCI 孔 (和其他裝置記憶體) 設定為 MTRR 中的 UC 時衝突的需求會發揮作用。因此即使 ACPI 對應要求 WB由於核心正確處理 MTRR 覆寫其仍會強制在核心的追踪中使用 UC-因此與驅動程式要求的 WC/UC- 相容。若在 SNP 和 TDX 來賓上強制執行 WB MTRR如果在專用驅動程式程式碼嘗試初始化裝置之前建立 ACPI 對應則 ACPI 對應會取得其要求的 WB。例如
    如果 acpi_init() 在探查對應裝置驅動程式之前執行則 ACPI 的 WB 對應會勝出並導致驅動程式的 ioremap() 失敗因為現有的 WB 對應與要求的 WC/UC- 不相容。例如當 Hypervisor 模擬 TPM (忽略仰賴據稱不受信任之實體儲存測量的安全性影響) 時TPM 驅動程式將要求 UC 且失敗 [ 1.730459] 0xfed40000-0xfed45000 的 ioremap 錯誤要求 0x2發生了 0x0 [ 1.732780] tpm_tis MSFT0101:00使用驅動程式 tpm_tis 探查失敗並出現錯誤 -12 請注意'0x2' 和 '0x0' 值是指 enum page_cache_mode 而非 x86 的 memtype (令人遺憾的是這幾乎是純粹的反轉2 == WB, 0 == UC)。例如追踪 TPM TIS 的對應要求會產生 Mapping TPM TIS with req_type = 0 警告 CPU
    22 PID1 在 arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 的模組連結CPU22 UID0 PID1 Commswapper/0 污染GW 6.16.0-rc7+ #2 VOLUNTARY 污染[W]=WARN 硬體名稱Google Google Compute Engine/Google Compute Engine、BIOS Google 05/29/2025 RIP0010:memtype_reserve+0x2ab/0x460
    __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i ---truncated--- (CVE-2025-40181)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  *通过强制变量 MTRR 范围实现的 UC。在大多数基于 KVM 的设置中通过 ACPI 枚举 HPET 和 TPM 等旧设备。ACPI 枚举包含 Memory32Fixed 条目以及 OperationRegion 的可选 SystemMemory 描述符例如需要通过 Control Method 访问设备时。如果存在 SystemMemory 条目则内核的 ACPI 驱动程序将 auto-ioremap 该区域以便可以随意访问。但是ACPI 规范未提供枚举 SystemMemory 区域内存类型的方式即无法告知软件某个区域必须映射为 UC 与非 UC。WB 等
    因此Linux 的 ACPI 驱动程序始终使用 ioremap_cache() 映射 SystemMemory 区域即 x86 上的 WB。但是专用设备驱动程序例如 HPET 驱动程序和 TPM 驱动程序希望将其关联的内存映射为 UC 或 WC因为不支持访问使用 WB 的 PCI 设备。在裸机和非 CoCO 上当固件将 PCI 漏洞和其他设备内存配置为 MTRR 中的 UC时冲突的要求生效。因此即使 ACPI 映射请求 WB，由于内核正确处理 MTRR 替代它们也会在内核的跟踪中被强制 UC-因此与驱动程序请求的 WC/UC- 兼容。当在 SNP 和 TDX 客户机上强制执行 WB MTRR 时如果在专用驱动程序代码尝试初始化设备之前建立 ACPI 映射则 ACPI 映射会获得其请求的 WB。例如
    如果 acpi_init() 在探测相应的设备驱动程序之前运行则 ACPI 的 WB 映射将会胜出并导致驱动程序的 ioremap() 失败因为现有的 WB 映射与请求的 WC/UC- 不兼容。例如当管理程序仿真 TPM时忽略依赖所谓不受信任的实体来存储测量值的安全影响TPM 驱动程序将请求 UC 并且失败[ 1.730459] 0xfed40000-0xfed45000 的 ioremap 错误请求了 0x2 、得到 0x0 [ 1.732780] tpm_tis MSFT0101:00驱动程序 tpm_tis 探测失败并出现错误 -12请注意“0x2”和“0x0”值是指 enum page_cache_mode而非 x86 的 memtype令人泄气的是它们几乎是纯粹的反转2 == WB，0 == UC。例如跟踪 TPM TIS 的映射请求会产生使用 req_type = 0 映射 TPM TIS 警告CPU
    22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 模块中链接了CPU: 22 UID: 0 PID: 1 Comm: swapper/0 受感染: GW 6.16.0-rc7+ #2 VOLUNTARY 受感染[W]=WARN 硬件名称Google Google Compute Engine/Google Compute EngineBIOS Google 05/29/2025 RIP0010:memtype_reserve+0x2ab/0x460
    __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i ---truncated--- (CVE-2025-40181)

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

ID	Name	Product	Family	Published	Updated	Severity
275354	Linux Distros Unpatched Vulnerability : CVE-2025-40181	Nessus	Misc.	11/13/2025	11/22/2025	high
275354	Linux Distros のパッチ未適用の脆弱性: CVE-2025-40181	Nessus	Misc.	11/13/2025	11/22/2025	high
275354	Linux Distros 未修補的弱點：CVE-2025-40181	Nessus	Misc.	11/13/2025	11/22/2025	high
275354	Linux Distros 未修补的漏洞：CVE-2025-40181	Nessus	Misc.	11/13/2025	11/22/2025	high

Detections

Analytics

Plugins Search

high

high

high

high