ntp_adjtime() should only validate constant with MOD_TIMECONST
ntp_adjtime() system call validates that the offset field in the
timex struct passed in is within a valid range, even if it has not been asked to set it.
This is different to other operating systems which ignore that value unless it is being set, and even then will silently correct an invalid value (FreeBSD, Linux)
and has led to workarounds appearing in various pieces of software, for example
https://github.com/mlichvar/chrony/blob/master/sys_timex.c#L262 has this:
#ifdef SOLARIS /* The kernel seems to check the constant even when it's not being set */ if (!(txc->modes & MOD_TIMECONST)) txc->constant = 10; #endif
Updated by Andy Fiddaman about 1 year ago
I tested this by building a custom version of ntpsec's
ntptime utility which takes an additional option which sets the 'constant' without setting MOD_TIMECONST in the modes. Before the patch, this would result in an error from the utility (EINVAL returned from the syscall), and now it does not.
I also successfully used the modified utility to set various values explicitly such as the constant itself and the frequency, in various combinations.
Updated by Electric Monk about 1 year ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit ea3cb02b50effb9ec1ecee7e7178c14143cd2485 Author: Andy Fiddaman <email@example.com> Date: 2021-12-06T16:50:59.000Z 14262 ntp_adjtime() should only validate constant with MOD_TIMECONST Reviewed by: Rich Lowe <firstname.lastname@example.org> Reviewed by: Jason King <email@example.com> Reviewed by: Toomas Soome <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>