CVE-2025-40181 (GCVE-0-2025-40181)
Vulnerability from cvelistv5
Published
2025-11-12 21:56
Modified
2025-11-12 21:56
Severity ?
VLAI Severity ?
EPSS score ?
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---
References
Impacted products
{
"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-rc1",
"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-rc1",
"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": "2025-11-12T21:56:25.930Z",
"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": "2025-11-12T21:56:25.930Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-40181\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-11-12T22:15:44.847\",\"lastModified\":\"2025-11-14T16:42:30.503\",\"vulnStatus\":\"Awaiting Analysis\",\"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---\"}],\"metrics\":{},\"references\":[{\"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\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…