A critical issue has been identified in the GPSD package, which is used to extract precise time and position data from GPS devices, due to which the time will shift back 24 weeks on October 1024, i.e. the time will be changed to March 2002. The issue appears in releases 3.20 through 3.22 inclusive and is resolved in GPSD 3.23. All users of systems that use GPSD need to install updates immediately, or be prepared for failure.
The effect of the error can lead to unpredictable failures on various systems, including those that do not directly use GPSD, since this application is used to obtain accurate time data on some NTP servers used for time synchronization. When time shifts occur in systems, problems may arise with authentication (for example, one-time passwords, Kerberos and other access verification mechanisms that have an expiration date will no longer work), with certificate verification, and with calculations that manipulate time ranges (for example, calculating the time of a user's session) . GPSD is also available on a variety of embedded and mobile devices, many of which no longer receive firmware updates.
The GPS protocol includes a week counter that counts the weeks since January 5, 1980. The problem is that during broadcasting, only 10 bits are allocated for this counter, which means it overflows every 1023 weeks (19.7 years). The first overflow occurred in 1999, the second in 2019, and the third will occur in 2038. These events are monitored by manufacturers and special handlers are provided for them. Currently, a new GPS message format (CNAV) has been introduced in parallel, in which 13 bits are allocated for the counter (i.e., an overflow is expected only in 2137).
In GPSD, in the logic for adjusting the appearance of an extra second (added to synchronize the world's reference atomic clocks with the Earth's astronomical time), an error was made due to which on October 24, 2021, 1024 will be subtracted prematurely from the week counter. According to the author of the code, the shift should have occurred on December 31, 2022, but the translation of this date into the number of weeks was not carried out correctly and in fact the number of weeks given in the check fell under October 2021 (the value indicated is 2180 instead of 2600). /* sanity check week number, GPS epoch, against leap seconds * Does not work well with regressions because the leap_sconds * could be from the receiver, or from BUILD_LEAPSECONDS. */ if (0 < session->context->leap_seconds && 19 > session->context->leap_seconds && 2180 < week) { /* assume leap second = 19 by 31 Dec 2022 * so week > 2180 is way in the future , do not allow it */ week -= 1024; GPSD_LOG(LOG_WARN, &session->context->errout, "GPS week confusion. Adjusted week %u for leap %d\n", week, session->context->leap_seconds); }
Source: opennet.ru