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 pcclocksettime()
As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64().
As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec 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 timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.
There are some drivers that use tp->tvsec and tp->tvnsec 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 hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
posix-clock: Fix missing timespec64 check in pcclocksettime()
As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp-info-settime64().
As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec 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 timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.
There are some drivers that use tp-tvsec and tp-tvnsec 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 hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.
— IBM
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1
Event History
Frequently Asked Questions
What is the severity of CVE-2024-50195?
The severity of CVE-2024-50195 is determined to be moderate due to its potential impact on the Linux kernel's timing operations.
How do I fix CVE-2024-50195?
To fix CVE-2024-50195, update your Linux kernel to a version that includes the security patch addressing this vulnerability.
Which Linux kernel versions are affected by CVE-2024-50195?
CVE-2024-50195 affects Linux kernel versions from 2.6.39 to 6.12-rc3, encompassing a wide range of releases.
What component of the Linux kernel is impacted by CVE-2024-50195?
CVE-2024-50195 impacts the posix-clock component within the Linux kernel.
Can CVE-2024-50195 lead to denial of service?
While CVE-2024-50195 primarily affects timing operations, it could potentially lead to a denial of service under certain conditions.