CVE-2024-50195: posix-clock: Fix missing timespec64 check in pc_clock_settime()
In the Linux kernel, the following vulnerability has been resolved:
posix-clock: Fix missing timespec64 check in pc_clock_settime()
As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp->info->settime64().
As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.
There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.
Security readout for executives and security teams
Plain-English summary
A local user could supply an invalid time value to a Linux Precision Time Protocol clock. Because the kernel failed to validate it before some drivers wrote hardware registers, the action could corrupt time-related state or disrupt the system. The supplied CVSS score is 7.1, reflecting high integrity and availability impact without disclosed confidentiality impact.
Executive priority
Prioritize remediation for multi-user, industrial, network-timing, and other PTP-dependent Linux systems. Treat it as a high-priority local integrity and availability issue, not an unauthenticated remote compromise. Use normal expedited kernel-patching processes and vendor-supported packages.
Technical view
pc_clock_settime() did not strictly validate timespec64 seconds and nanoseconds before invoking a PTP driver's settime64 handler. Some drivers directly used those fields for hardware-register writes while assuming validation occurred upstream. Stable fixes add timespec64_valid_strict() and return EINVAL for invalid values.
Likely exposure
Exposure is most likely on affected Linux systems using PTP hardware or dynamic PTP clocks. The CVSS vector requires local access and low privileges. The bundle identifies affected releases spanning Linux 2.6.39 through named stable versions including 6.12, but exact distribution-specific status must be confirmed through vendor advisories.
Exploitation context
The supplied record does not indicate CISA KEV listing or active exploitation. No cited source in the bundle claims public exploitation. Exploitation requires local access according to the CVSS vector, reducing internet-facing risk, while potential integrity and availability consequences remain significant on accessible PTP-enabled systems.
Researcher notes
The defect is improper exceptional-condition handling, classified as CWE-754. Driver examples named by the source include hclge, igb i210, and Renesas R-Car Gen4 PTP implementations, but these are examples rather than a complete affected-driver list. The supplied affected-version data is not a precise branch range, so commit or distribution-level verification is necessary.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix.
Check distribution advisories for the corrected package version for each deployed release.
Restrict local access and privileges on affected systems until updates are applied.
Prioritize PTP-enabled systems and hosts using drivers that directly program clock registers.
Validation and detection
Inventory deployed kernel versions and identify systems using PTP clocks or hardware.
Confirm vendor package changelogs include the CVE or corresponding stable-kernel fix.
Verify patched kernels reject invalid PTP time values with EINVAL in authorized testing.
Reboot updated hosts and confirm the corrected kernel is running.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-754: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-754 · source CWE mapping
Improper Check for Unusual or Exceptional Conditions
Improper Check for Unusual or Exceptional Conditions represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.