CVE-2025-38508 (GCVE-0-2025-38508)
Vulnerability from cvelistv5
Published
2025-08-16 10:54
Modified
2026-08-05 12:02
Severity ?
7.3 (High) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: x86/sev: Use TSC_FACTOR for Secure TSC frequency calculation When using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on the nominal P0 frequency, which deviates slightly (typically ~0.2%) from the actual mean TSC frequency due to clocking parameters. Over extended VM uptime, this discrepancy accumulates, causing clock skew between the hypervisor and a SEV-SNP VM, leading to early timer interrupts as perceived by the guest. The guest kernel relies on the reported nominal frequency for TSC-based timekeeping, while the actual frequency set during SNP_LAUNCH_START may differ. This mismatch results in inaccurate time calculations, causing the guest to perceive hrtimers as firing earlier than expected. Utilize the TSC_FACTOR from the SEV firmware's secrets page (see "Secrets Page Format" in the SNP Firmware ABI Specification) to calculate the mean TSC frequency, ensuring accurate timekeeping and mitigating clock skew in SEV-SNP VMs. Use early_ioremap_encrypted() to map the secrets page as ioremap_encrypted() uses kmalloc() which is not available during early TSC initialization and causes a panic. [ bp: Drop the silly dummy var: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ]
References
Impacted products
Vendor Product Version
Linux Linux Version: 73bbf3b0fbba9aa27fef07a1fbd837661a863f03
Version: 73bbf3b0fbba9aa27fef07a1fbd837661a863f03
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/coco/sev/core.c",
            "arch/x86/include/asm/sev.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d0195c42e65805938c9eb507657e7cdf8e1e9522",
              "status": "affected",
              "version": "73bbf3b0fbba9aa27fef07a1fbd837661a863f03",
              "versionType": "git"
            },
            {
              "lessThan": "52e1a03e6cf61ae165f59f41c44394a653a0a788",
              "status": "affected",
              "version": "73bbf3b0fbba9aa27fef07a1fbd837661a863f03",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/coco/sev/core.c",
            "arch/x86/include/asm/sev.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "lessThan": "6.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.15.*",
              "status": "unaffected",
              "version": "6.15.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.16",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15.7",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.16",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027s 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": {
            "baseScore": 7.3,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
            "version": "3.1"
          },
          "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 \u2014 the untrusted hypervisor, or any local guest workload depending on the clock \u2014 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\u0027s 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 \u2014 the wrong TSC frequency is computed automatically on every boot of an affected guest and locked in for the VM\u0027s 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\u0027s 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 \u2014 precisely the data Secure TSC is designed to protect the integrity of against an untrusted host \u2014 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 \u2014 `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\u0027s 500 ppm `MAXFREQ`, so hrtimers misfire and the clock drifts ~3 min/day for the VM\u0027s 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 \u2014 the fix\u0027s use of `sev_es_terminate()` on failure shows maintainers treat a bad Secure TSC frequency as fatal."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:02:31.621Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38508",
    "datePublished": "2025-08-16T10:54:45.567Z",
    "dateReserved": "2025-04-16T04:51:24.022Z",
    "dateUpdated": "2026-08-05T12:02:31.621Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.