CVE-2025-40181 (GCVE-0-2025-40181)

Vulnerability from cvelistv5 – Published: 2025-11-12 21:56 – Updated: 2026-05-11 21:44
VLAI
Title
x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP
Summary
In the Linux kernel, the following vulnerability has been resolved: 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---
Severity
No CVSS data available.
Assigner
Linux CNA under the mitre root
CNA scorecard D 53/100 over 6992 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 8e690b817e38769dc2fa0e7473e5a5dc1fc25795 , < 34ff466f74d0fe1db8956f9c245e2bb2c67f67bf (git)
Affected: 8e690b817e38769dc2fa0e7473e5a5dc1fc25795 , < 91ab8a21bda2d2d2842b6159ac060d9100433a3c (git)
Affected: 8e690b817e38769dc2fa0e7473e5a5dc1fc25795 , < 0dccbc75e18df85399a71933d60b97494110f559 (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.12
Unaffected: 0 , < 6.12 (semver)
Unaffected: 6.12.54 , ≤ 6.12.* (semver)
Unaffected: 6.17.4 , ≤ 6.17.* (semver)
Unaffected: 6.18 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kernel/kvm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "34ff466f74d0fe1db8956f9c245e2bb2c67f67bf",
              "status": "affected",
              "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
              "versionType": "git"
            },
            {
              "lessThan": "91ab8a21bda2d2d2842b6159ac060d9100433a3c",
              "status": "affected",
              "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
              "versionType": "git"
            },
            {
              "lessThan": "0dccbc75e18df85399a71933d60b97494110f559",
              "status": "affected",
              "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kernel/kvm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.12"
            },
            {
              "lessThan": "6.12",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.54",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.54",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17.4",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP\n\nWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,\ni.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC\nvia a forced variable MTRR range.\n\nIn most KVM-based setups, legacy devices such as the HPET and TPM are\nenumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and\noptionally a SystemMemory descriptor for an OperationRegion, e.g. if the\ndevice needs to be accessed via a Control Method.\n\nIf a SystemMemory entry is present, then the kernel\u0027s ACPI driver will\nauto-ioremap the region so that it can be accessed at will.  However, the\nACPI spec doesn\u0027t provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there\u0027s no way to tell software that a region\nmust be mapped as UC vs. WB, etc.  As a result, Linux\u0027s ACPI driver always\nmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.\n\nThe dedicated device drivers however, e.g. the HPET driver and TPM driver,\nwant to map their associated memory as UC or WC, as accessing PCI devices\nusing WB is unsupported.\n\nOn bare metal and non-CoCO, the conflicting requirements \"work\" as firmware\nconfigures the PCI hole (and other device memory) to be UC in the MTRRs.\nSo even though the ACPI mappings request WB, they are forced to UC- in the\nkernel\u0027s tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers\u0027 requested WC/UC-.\n\nWith force WB MTRRs on SNP and TDX guests, the ACPI mappings get their\nrequested WB if the ACPI mappings are established before the dedicated\ndriver code attempts to initialize the device.  E.g. if acpi_init()\nruns before the corresponding device driver is probed, ACPI\u0027s WB mapping\nwill \"win\", and result in the driver\u0027s ioremap() failing because the\nexisting WB mapping isn\u0027t compatible with the requested WC/UC-.\n\nE.g. when a TPM is emulated by the hypervisor (ignoring the security\nimplications of relying on what is allegedly an untrusted entity to store\nmeasurements), the TPM driver will request UC and fail:\n\n  [  1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0\n  [  1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12\n\nNote, the \u00270x2\u0027 and \u00270x0\u0027 values refer to \"enum page_cache_mode\", not x86\u0027s\nmemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).\nE.g. tracing mapping requests for TPM TIS yields:\n\n Mapping TPM TIS with req_type = 0\n WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\n Modules linked in:\n CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.16.0-rc7+ #2 VOLUNTARY\n Tainted: [W]=WARN\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\n RIP: 0010:memtype_reserve+0x2ab/0x460\n  __ioremap_caller+0x16d/0x3d0\n  ioremap_cache+0x17/0x30\n  x86_acpi_os_ioremap+0xe/0x20\n  acpi_os_map_iomem+0x1f3/0x240\n  acpi_os_map_memory+0xe/0x20\n  acpi_ex_system_memory_space_handler+0x273/0x440\n  acpi_ev_address_space_dispatch+0x176/0x4c0\n  acpi_ex_access_region+0x2ad/0x530\n  acpi_ex_field_datum_io+0xa2/0x4f0\n  acpi_ex_extract_from_field+0x296/0x3e0\n  acpi_ex_read_data_from_field+0xd1/0x460\n  acpi_ex_resolve_node_to_value+0x2ee/0x530\n  acpi_ex_resolve_to_value+0x1f2/0x540\n  acpi_ds_evaluate_name_path+0x11b/0x190\n  acpi_ds_exec_end_op+0x456/0x960\n  acpi_ps_parse_loop+0x27a/0xa50\n  acpi_ps_parse_aml+0x226/0x600\n  acpi_ps_execute_method+0x172/0x3e0\n  acpi_ns_evaluate+0x175/0x5f0\n  acpi_evaluate_object+0x213/0x490\n  acpi_evaluate_integer+0x6d/0x140\n  acpi_bus_get_status+0x93/0x150\n  acpi_add_single_object+0x43a/0x7c0\n  acpi_bus_check_add+0x149/0x3a0\n  acpi_bus_check_add_1+0x16/0x30\n  acpi_ns_walk_namespace+0x22c/0x360\n  acpi_walk_namespace+0x15c/0x170\n  acpi_bus_scan+0x1dd/0x200\n  acpi_scan_init+0xe5/0x2b0\n  acpi_init+0x264/0x5b0\n  do_one_i\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:44:19.679Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/34ff466f74d0fe1db8956f9c245e2bb2c67f67bf"
        },
        {
          "url": "https://git.kernel.org/stable/c/91ab8a21bda2d2d2842b6159ac060d9100433a3c"
        },
        {
          "url": "https://git.kernel.org/stable/c/0dccbc75e18df85399a71933d60b97494110f559"
        }
      ],
      "title": "x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-40181",
    "datePublished": "2025-11-12T21:56:25.930Z",
    "dateReserved": "2025-04-16T07:20:57.177Z",
    "dateUpdated": "2026-05-11T21:44:19.679Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-40181",
      "date": "2026-10-20",
      "epss": "0.00213",
      "percentile": "0.10977"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "arch/x86/kernel/kvm.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "34ff466f74d0fe1db8956f9c245e2bb2c67f67bf",
                    "status": "affected",
                    "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "91ab8a21bda2d2d2842b6159ac060d9100433a3c",
                    "status": "affected",
                    "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "0dccbc75e18df85399a71933d60b97494110f559",
                    "status": "affected",
                    "version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "arch/x86/kernel/kvm.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.12"
                  },
                  {
                    "lessThan": "6.12",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.54",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.17.*",
                    "status": "unaffected",
                    "version": "6.17.4",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.18",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP\n\nWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,\ni.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC\nvia a forced variable MTRR range.\n\nIn most KVM-based setups, legacy devices such as the HPET and TPM are\nenumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and\noptionally a SystemMemory descriptor for an OperationRegion, e.g. if the\ndevice needs to be accessed via a Control Method.\n\nIf a SystemMemory entry is present, then the kernel\u0027s ACPI driver will\nauto-ioremap the region so that it can be accessed at will.  However, the\nACPI spec doesn\u0027t provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there\u0027s no way to tell software that a region\nmust be mapped as UC vs. WB, etc.  As a result, Linux\u0027s ACPI driver always\nmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.\n\nThe dedicated device drivers however, e.g. the HPET driver and TPM driver,\nwant to map their associated memory as UC or WC, as accessing PCI devices\nusing WB is unsupported.\n\nOn bare metal and non-CoCO, the conflicting requirements \"work\" as firmware\nconfigures the PCI hole (and other device memory) to be UC in the MTRRs.\nSo even though the ACPI mappings request WB, they are forced to UC- in the\nkernel\u0027s tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers\u0027 requested WC/UC-.\n\nWith force WB MTRRs on SNP and TDX guests, the ACPI mappings get their\nrequested WB if the ACPI mappings are established before the dedicated\ndriver code attempts to initialize the device.  E.g. if acpi_init()\nruns before the corresponding device driver is probed, ACPI\u0027s WB mapping\nwill \"win\", and result in the driver\u0027s ioremap() failing because the\nexisting WB mapping isn\u0027t compatible with the requested WC/UC-.\n\nE.g. when a TPM is emulated by the hypervisor (ignoring the security\nimplications of relying on what is allegedly an untrusted entity to store\nmeasurements), the TPM driver will request UC and fail:\n\n  [  1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0\n  [  1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12\n\nNote, the \u00270x2\u0027 and \u00270x0\u0027 values refer to \"enum page_cache_mode\", not x86\u0027s\nmemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).\nE.g. tracing mapping requests for TPM TIS yields:\n\n Mapping TPM TIS with req_type = 0\n WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\n Modules linked in:\n CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.16.0-rc7+ #2 VOLUNTARY\n Tainted: [W]=WARN\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\n RIP: 0010:memtype_reserve+0x2ab/0x460\n  __ioremap_caller+0x16d/0x3d0\n  ioremap_cache+0x17/0x30\n  x86_acpi_os_ioremap+0xe/0x20\n  acpi_os_map_iomem+0x1f3/0x240\n  acpi_os_map_memory+0xe/0x20\n  acpi_ex_system_memory_space_handler+0x273/0x440\n  acpi_ev_address_space_dispatch+0x176/0x4c0\n  acpi_ex_access_region+0x2ad/0x530\n  acpi_ex_field_datum_io+0xa2/0x4f0\n  acpi_ex_extract_from_field+0x296/0x3e0\n  acpi_ex_read_data_from_field+0xd1/0x460\n  acpi_ex_resolve_node_to_value+0x2ee/0x530\n  acpi_ex_resolve_to_value+0x1f2/0x540\n  acpi_ds_evaluate_name_path+0x11b/0x190\n  acpi_ds_exec_end_op+0x456/0x960\n  acpi_ps_parse_loop+0x27a/0xa50\n  acpi_ps_parse_aml+0x226/0x600\n  acpi_ps_execute_method+0x172/0x3e0\n  acpi_ns_evaluate+0x175/0x5f0\n  acpi_evaluate_object+0x213/0x490\n  acpi_evaluate_integer+0x6d/0x140\n  acpi_bus_get_status+0x93/0x150\n  acpi_add_single_object+0x43a/0x7c0\n  acpi_bus_check_add+0x149/0x3a0\n  acpi_bus_check_add_1+0x16/0x30\n  acpi_ns_walk_namespace+0x22c/0x360\n  acpi_walk_namespace+0x15c/0x170\n  acpi_bus_scan+0x1dd/0x200\n  acpi_scan_init+0xe5/0x2b0\n  acpi_init+0x264/0x5b0\n  do_one_i\n---truncated---"
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nx86/kvm: Forzar el \u201cagujero\u201d PCI heredado a UC al anular los MTRR para TDX/SNP\n\nAl ejecutarse como un invitado SNP o TDX bajo KVM, se fuerza que el \u201cagujero\u201d PCI heredado, es decir, la memoria entre la parte superior de la DRAM utilizable inferior y 4 GiB, se mapee como UC a trav\u00e9s de un rango MTRR variable forzado.\n\nEn la mayor\u00eda de las configuraciones basadas en KVM, los dispositivos heredados como el HPET y el TPM se enumeran a trav\u00e9s de ACPI. La enumeraci\u00f3n ACPI incluye una entrada Memory32Fixed y, opcionalmente, un descriptor SystemMemory para una OperationRegion, por ejemplo, si se necesita acceder al dispositivo a trav\u00e9s de un m\u00e9todo de control.\n\nSi una entrada SystemMemory est\u00e1 presente, entonces el controlador ACPI del kernel remapear\u00e1 autom\u00e1ticamente la regi\u00f3n para que pueda ser accedida a voluntad. Sin embargo, la especificaci\u00f3n ACPI no proporciona una forma de enumerar el tipo de memoria de las regiones SystemMemory, es decir, no hay forma de indicarle al software que una regi\u00f3n debe mapearse como UC frente a WB, etc. Como resultado, el controlador ACPI de Linux siempre mapea las regiones SystemMemory usando ioremap_cache(), es decir, como WB en x86.\n\nSin embargo, los controladores de dispositivos dedicados, por ejemplo, el controlador HPET y el controlador TPM, quieren mapear su memoria asociada como UC o WC, ya que el acceso a dispositivos PCI usando WB no es compatible.\n\nEn hardware \u201cbare metal\u201d y no-CoCO, los requisitos conflictivos \u201cfuncionan\u201d ya que el firmware configura el \u201cagujero\u201d PCI (y otra memoria de dispositivo) para que sea UC en los MTRR. As\u00ed, aunque los mapeos ACPI soliciten WB, se fuerzan a UC- en el seguimiento del kernel debido a que el kernel maneja correctamente las anulaciones de MTRR, y por lo tanto son compatibles con los WC/UC- solicitados por los controladores.\n\nCon MTRR de WB forzados en invitados SNP y TDX, los mapeos ACPI obtienen su WB solicitado si los mapeos ACPI se establecen antes de que el c\u00f3digo del controlador dedicado intente inicializar el dispositivo. Por ejemplo, si acpi_init() se ejecuta antes de que se sondee el controlador de dispositivo correspondiente, el mapeo WB de ACPI \u201cganar\u00e1\u201d y resultar\u00e1 en que el ioremap() del controlador falle porque el mapeo WB existente no es compatible con el WC/UC- solicitado.\n\nPor ejemplo, cuando un TPM es emulado por el hipervisor (ignorando las implicaciones de seguridad de depender de lo que supuestamente es una entidad no confiable para almacenar mediciones), el controlador TPM solicitar\u00e1 UC y fallar\u00e1:\n\n  [  1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0\n  [  1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12\n\nTenga en cuenta que los valores \u00270x2\u0027 y \u00270x0\u0027 se refieren a \u201cenum page_cache_mode\u201d, no a los tipos de memoria de x86 (que, frustrantemente, son una inversi\u00f3n casi pura; 2 == WB, 0 == UC). Por ejemplo, el rastreo de solicitudes de mapeo para TPM TIS arroja:\n\n Mapping TPM TIS with req_type = 0\n WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\n Modules linked in:\n CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.16.0-rc7+ #2 VOLUNTARY\n Tainted: [W]=WARN\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\n RIP: 0010:memtype_reserve+0x2ab/0x460\n  __ioremap_caller+0x16d/0x3d0\n  ioremap_cache+0x17/0x30\n  x86_acpi_os_ioremap+0xe/0x20\n  acpi_os_map_iomem+0x1f3/0x240\n  acpi_os_map_memory+0xe/0x20\n  acpi_ex_system_memory_space_handler+0x273/0x440\n  acpi_ev_address_space_dispatch+0x176/0x4c0\n  acpi_ex_access_region+0x2ad/0x530\n  acpi_ex_field_datum_io+0xa2/0x4f0\n  acpi_ex_extract_from_field+0x296/0x3e0\n  acpi_ex_read_data_from_field+0xd1/0x460\n  acpi_ex_resolve_node_to_value+0x2ee/0x530\n  acpi_ex_resolve_to_value+0x1f2/0x540\n  acpi_ds_evaluate_name_path+0x11b/0x190\n  --TRUNCADO--"
          }
        ],
        "id": "CVE-2025-40181",
        "lastModified": "2026-10-19T21:10:00.160",
        "metrics": {},
        "published": "2025-11-12T22:15:44.847",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/0dccbc75e18df85399a71933d60b97494110f559"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/34ff466f74d0fe1db8956f9c245e2bb2c67f67bf"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/91ab8a21bda2d2d2842b6159ac060d9100433a3c"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Deferred"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-09-15T18:09:23+00:00",
      "cve": "CVE-2025-40181",
      "id": "CVE-2025-40181",
      "initial_release_date": "2025-11-12T00:00:00+00:00",
      "product_status:known_affected": "198",
      "product_status:known_not_affected": "76",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-40181.json",
      "version": "3"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.