{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2025-38508", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-04-16T04:51:24.022Z", "datePublished": "2025-08-16T10:54:45.567Z", "dateUpdated": "2026-08-05T12:02:31.621Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T12:02:31.621Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Use TSC_FACTOR for Secure TSC frequency calculation\n\nWhen using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on\nthe nominal P0 frequency, which deviates slightly (typically ~0.2%) from\nthe actual mean TSC frequency due to clocking parameters.\n\nOver extended VM uptime, this discrepancy accumulates, causing clock skew\nbetween the hypervisor and a SEV-SNP VM, leading to early timer interrupts as\nperceived by the guest.\n\nThe guest kernel relies on the reported nominal frequency for TSC-based\ntimekeeping, while the actual frequency set during SNP_LAUNCH_START may\ndiffer. This mismatch results in inaccurate time calculations, causing the\nguest to perceive hrtimers as firing earlier than expected.\n\nUtilize the TSC_FACTOR from the SEV firmware's secrets page (see \"Secrets\nPage Format\" in the SNP Firmware ABI Specification) to calculate the mean\nTSC frequency, ensuring accurate timekeeping and mitigating clock skew in\nSEV-SNP VMs.\n\nUse early_ioremap_encrypted() to map the secrets page as\nioremap_encrypted() uses kmalloc() which is not available during early TSC\ninitialization and causes a panic.\n\n [ bp: Drop the silly dummy var:\n https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ]" } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H", "baseScore": 7.3, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - The defect is in guest early-boot code (`snp_secure_tsc_init()` called from `tsc_early_init()`), reached via a local MSR read on the SEV-SNP guest CPU with no network input of any kind. The relevant adversary in the SNP threat model — the untrusted hypervisor, or any local guest workload depending on the clock — operates locally to the machine, which maps to Local.\nAC:L - The miscalculation is fully deterministic: every Secure TSC SNP guest boot reads the nominal P0 frequency and is off by the platform's TSC_FACTOR, with no race, memory-layout, or timing dependency. SEV-SNP with Secure TSC is a mainstream confidential-computing deployment on current AMD server silicon and `CONFIG_AMD_MEM_ENCRYPT` is enabled in all distro kernels, so no rare configuration is required.\nPR:N - The flaw manifests during `tsc_early_init()` before any userspace or credential exists, so no privileges are held or required at any point on the path. Both the untrusted hypervisor and every unprivileged process in the guest are affected without authenticating to anything.\nUI:N - No victim action is needed — the wrong TSC frequency is computed automatically on every boot of an affected guest and locked in for the VM's lifetime. Nothing must be mounted, opened, or configured by a user.\nS:U - The vulnerable component (guest kernel SEV/TSC init) and the impacted component (that same guest kernel's timekeeping and the workloads relying on it) are within the single security authority of the confidential VM. The hypervisor, IOMMU, and host memory are not reached, so no boundary is crossed.\nC:L - A guest clock that runs uncorrectably slow causes the guest to accept TLS server certificates, Kerberos tickets, and bearer tokens that have actually expired, and destroys the freshness guarantee of timestamped SNP attestation reports, so protected data can be disclosed to peers whose credentials should have been rejected. This is a limited, indirect disclosure rather than arbitrary memory read.\nI:L - Guest monotonic and wall-clock time — precisely the data Secure TSC is designed to protect the integrity of against an untrusted host — is silently and permanently wrong, corrupting log and audit timestamps, credential-expiry decisions, and timer deadlines. The modification is bounded and not attacker-directed, so it is limited rather than a full loss of integrity.\nA:H - The bad frequency is unrecoverable — `X86_FEATURE_TSC_KNOWN_FREQ` makes `init_tsc_clocksource()` skip refined calibration entirely, there is no trusted watchdog clocksource in an SNP guest, and the 2000 ppm error is 4x beyond the kernel NTP discipline's 500 ppm `MAXFREQ`, so hrtimers misfire and the clock drifts ~3 min/day for the VM's whole lifetime, evicting the node from lease/heartbeat-based services (etcd, Ceph, Kerberos, cluster quorum). Additionally, the unmasked reserved bits [63:18] of `GUEST_TSC_FREQ` can produce a wildly bogus `tsc_khz`, breaking `udelay()`, `loops_per_jiffy`, and `sched_clock` and hanging the guest — the fix's use of `sev_es_terminate()` on failure shows maintainers treat a bad Secure TSC frequency as fatal." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "arch/x86/coco/sev/core.c", "arch/x86/include/asm/sev.h" ], "versions": [ { "version": "73bbf3b0fbba9aa27fef07a1fbd837661a863f03", "lessThan": "d0195c42e65805938c9eb507657e7cdf8e1e9522", "status": "affected", "versionType": "git" }, { "version": "73bbf3b0fbba9aa27fef07a1fbd837661a863f03", "lessThan": "52e1a03e6cf61ae165f59f41c44394a653a0a788", "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/coco/sev/core.c", "arch/x86/include/asm/sev.h" ], "versions": [ { "version": "6.14", "status": "affected" }, { "version": "0", "lessThan": "6.14", "status": "unaffected", "versionType": "semver" }, { "version": "6.15.7", "lessThanOrEqual": "6.15.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.16", "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.14", "versionEndExcluding": "6.15.7" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.14", "versionEndExcluding": "6.16" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/d0195c42e65805938c9eb507657e7cdf8e1e9522" }, { "url": "https://git.kernel.org/stable/c/52e1a03e6cf61ae165f59f41c44394a653a0a788" } ], "title": "x86/sev: Use TSC_FACTOR for Secure TSC frequency calculation", "x_generator": { "engine": "bippy-1.2.0" } } } }