svn commit: r325825 - head/sys/kern
Bruce Evans
brde at optusnet.com.au
Wed Nov 15 10:57:59 UTC 2017
On Tue, 14 Nov 2017, Ed Maste wrote:
> Log:
> disallow clock_settime too far in the future to avoid panic
>
> clock_ts_to_ct has a KASSERT that the converted year fits into four
> digits. By default (sysctl debug.allow_insane_settime is 0) the kernel
> disallows a time too far in the future, using a value of 9999 366-day
> years. However, clock_settime is epoch-relative and the assertion will
> fail with a tv_sec corresponding to some 8030 years.
>
> Avoid trying to be too clever, and just use a limit of 8000 365-day
> years past the epoch.
>
> Submitted by: Heqing Yan <scottieyan at gmail.com>
> Reported by: Syzkaller (https://github.com/google/syzkaller)
> MFC after: 1 week
> Sponsored by: The FreeBSD Foundation
I reported this panic and several others in reply to previous attempted fixes.
> Modified: head/sys/kern/kern_time.c
> ==============================================================================
> --- head/sys/kern/kern_time.c Tue Nov 14 18:17:23 2017 (r325824)
> +++ head/sys/kern/kern_time.c Tue Nov 14 18:18:18 2017 (r325825)
> @@ -408,7 +408,7 @@ kern_clock_settime(struct thread *td, clockid_t clock_
> if (ats->tv_nsec < 0 || ats->tv_nsec >= 1000000000 ||
> ats->tv_sec < 0)
> return (EINVAL);
> - if (!allow_insane_settime && ats->tv_sec > 9999ULL * 366 * 24 * 60 * 60)
> + if (!allow_insane_settime && ats->tv_sec > 8000ULL * 365 * 24 * 60 * 60)
> return (EINVAL);
> /* XXX Don't convert nsec->usec and back */
> TIMESPEC_TO_TIMEVAL(&atv, ats);
Panics still occur when year 10K is reached via:
tv_sec = 8000ULL * 365 * 24 * 60 * 60 - 1 (approx. 7994.5 years)
POSIX Epoch offset = 1970 years
utc_offset() <= (approx. 7994.5 + 1970) - 100000 = approx. -36.5 years
(utc_offset() in seconds is the combined timezone offset
60 * tz.tz_minuteswest + (wall_cmos_clock ? adjkerntz : 0).)
A utc_offset() of -36.5 years is preposterous but easy to reach without
overflow (utc_offset() has blind overflow at approx. +-69 years).
For 32-bit time_t, both of the above abominable ULL checks are vacuously
false, but panics still occurs for all widths of time_t with non-
preposterous values near the Epoch:
tv_sec = 0 (Epoch in UTC)
utc_offset() = 10 * 60 (garbage or panic in RTC; should be 1969)
Wthout INVARIANTS, this writes the RTC with the garbage time 70/01/01
00:5c:05, where at least the 5c is from a buffer overrun. With
INVARIANTS, garbage produced by clock_tv_to_ct() is detected there.
tv_sec = INT_MAX (2038 in UTC)
utc_offset() = -1 (garbage or panic in RTC; should be EINVAL)
This takes 32-bit time_t. Then tv_sec - utc_offset() blindly overflows
to INT_MIN on supported arches. The resulting garbage or panic in the
RTC is not much worse than for any other negative value of
tv_sec - utc_offset().
The settime() level doesn't know about utc_offset() (except for the
historical mistake of setting the timezone using settimeofday()), and
this is correct. Only the RTC level uses utc_offset() (or the timezone).
The correct error handling is to not KASSERT() anything, but avoid overflow
and just don't continue after overflow or set the RTC to a preposterous
or unportable value.
Bruce
More information about the svn-src-all
mailing list