{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2025-40181", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-04-16T07:20:57.177Z", "datePublished": "2025-11-12T21:56:25.930Z", "dateUpdated": "2025-11-12T21:56:25.930Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-11-12T21:56:25.930Z"}, "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's ACPI driver will\nauto-ioremap the region so that it can be accessed at will. However, the\nACPI spec doesn't provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there's no way to tell software that a region\nmust be mapped as UC vs. WB, etc. As a result, Linux's 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's tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers' 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's WB mapping\nwill \"win\", and result in the driver's ioremap() failing because the\nexisting WB mapping isn't 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 '0x2' and '0x0' values refer to \"enum page_cache_mode\", not x86's\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---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/x86/kernel/kvm.c"], "versions": [{"version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795", "lessThan": "34ff466f74d0fe1db8956f9c245e2bb2c67f67bf", "status": "affected", "versionType": "git"}, {"version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795", "lessThan": "91ab8a21bda2d2d2842b6159ac060d9100433a3c", "status": "affected", "versionType": "git"}, {"version": "8e690b817e38769dc2fa0e7473e5a5dc1fc25795", "lessThan": "0dccbc75e18df85399a71933d60b97494110f559", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/x86/kernel/kvm.c"], "versions": [{"version": "6.12", "status": "affected"}, {"version": "0", "lessThan": "6.12", "status": "unaffected", "versionType": "semver"}, {"version": "6.12.54", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.17.4", "lessThanOrEqual": "6.17.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.18-rc1", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.12", "versionEndExcluding": "6.12.54"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.12", "versionEndExcluding": "6.17.4"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.12", "versionEndExcluding": "6.18-rc1"}]}]}], "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"}}}}

{}

{"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's ACPI driver will\nauto-ioremap the region so that it can be accessed at will. However, the\nACPI spec doesn't provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there's no way to tell software that a region\nmust be mapped as UC vs. WB, etc. As a result, Linux's 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's tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers' 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's WB mapping\nwill \"win\", and result in the driver's ioremap() failing because the\nexisting WB mapping isn't 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 '0x2' and '0x0' values refer to \"enum page_cache_mode\", not x86's\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---"}], "id": "CVE-2025-40181", "lastModified": "2025-11-14T16:42:30.503", "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": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP", "id": "2414706", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2414706"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.0", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nx86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP\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.\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.\nIf a SystemMemory entry is present, then the kernel's ACPI driver will\nauto-ioremap the region so that it can be accessed at will. However, the\nACPI spec doesn't provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there's no way to tell software that a region\nmust be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver always\nmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.\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.\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's tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers' requested WC/UC-.\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's WB mapping\nwill \"win\", and result in the driver's ioremap() failing because the\nexisting WB mapping isn't compatible with the requested WC/UC-.\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[ 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\nNote, the '0x2' and '0x0' values refer to \"enum page_cache_mode\", not x86's\nmemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).\nE.g. tracing mapping requests for TPM TIS yields:\nMapping TPM TIS with req_type = 0\nWARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\nModules linked in:\nCPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY\nTainted: [W]=WARN\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\nRIP: 0010:memtype_reserve+0x2ab/0x460\n__ioremap_caller+0x16d/0x3d0\nioremap_cache+0x17/0x30\nx86_acpi_os_ioremap+0xe/0x20\nacpi_os_map_iomem+0x1f3/0x240\nacpi_os_map_memory+0xe/0x20\nacpi_ex_system_memory_space_handler+0x273/0x440\nacpi_ev_address_space_dispatch+0x176/0x4c0\nacpi_ex_access_region+0x2ad/0x530\nacpi_ex_field_datum_io+0xa2/0x4f0\nacpi_ex_extract_from_field+0x296/0x3e0\nacpi_ex_read_data_from_field+0xd1/0x460\nacpi_ex_resolve_node_to_value+0x2ee/0x530\nacpi_ex_resolve_to_value+0x1f2/0x540\nacpi_ds_evaluate_name_path+0x11b/0x190\nacpi_ds_exec_end_op+0x456/0x960\nacpi_ps_parse_loop+0x27a/0xa50\nacpi_ps_parse_aml+0x226/0x600\nacpi_ps_execute_method+0x172/0x3e0\nacpi_ns_evaluate+0x175/0x5f0\nacpi_evaluate_object+0x213/0x490\nacpi_evaluate_integer+0x6d/0x140\nacpi_bus_get_status+0x93/0x150\nacpi_add_single_object+0x43a/0x7c0\nacpi_bus_check_add+0x149/0x3a0\nacpi_bus_check_add_1+0x16/0x30\nacpi_ns_walk_namespace+0x22c/0x360\nacpi_walk_namespace+0x15c/0x170\nacpi_bus_scan+0x1dd/0x200\nacpi_scan_init+0xe5/0x2b0\nacpi_init+0x264/0x5b0\ndo_one_i\n---truncated---"], "name": "CVE-2025-40181", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-11-12T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2025-40181\nhttps://nvd.nist.gov/vuln/detail/CVE-2025-40181\nhttps://lore.kernel.org/linux-cve-announce/2025111243-CVE-2025-40181-f51c@gregkh/T"], "threat_severity": "Moderate"}

{"created": "2025-11-13T09:52:10.681789+00:00", "updated": "2025-11-13T09:52:10.681817+00:00", "vendors": ["linux", "linux$PRODUCT$linux_kernel"]}