[PATCH] ntp: Fixup adjtimex freq validation on 32bit systems

[PATCH] ntp: Fixup adjtimex freq validation on 32bit systems

[John Stultz]

For tip/timers/urgent.

Additional validation of adjtimex freq values to avoid
potential multiplication overflows were added in commit
5e5aeb4367b (time: adjtimex: Validate the ADJ_FREQUENCY values)

Unfortunately the patch used LONG_MAX/MIN instead of
LLONG_MAX/MIN, which was fine on 64bit systems, but being
much smaller on 32bit systems caused false positives
resulting in most direct frequency adjustments to fail w/
EINVAL.

ntpd only does direct frequency adjustments at startup, so
the issue was not as easily observed there, but other time
sync applications like ptpd and chrony were more effected by
the bug.

See bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=92481
https://bugzilla.redhat.com/show_bug.cgi?id=1188074

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: stable@vger.kernel.org
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
One note:
0day kbuild bot complains about
>> kernel/time/ntp.c:637: warning: comparison is always false due to limited range of data type
>> kernel/time/ntp.c:639: warning: comparison is always false due to limited range of data type

We could fix this via adding an extra (BITS_PER_LONG == 64)
case before we check these to avoid it, but that seemed a
bit too ugly to me. Thoughts?

 kernel/time/ntp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 28bf91c..242774d 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -634,9 +634,9 @@ int ntp_validate_timex(struct timex *txc)
 		return -EPERM;
 
 	if (txc->modes & ADJ_FREQUENCY) {
-		if (LONG_MIN / PPM_SCALE > txc->freq)
+		if (LLONG_MIN / PPM_SCALE > txc->freq)
 			return -EINVAL;
-		if (LONG_MAX / PPM_SCALE < txc->freq)
+		if (LLONG_MAX / PPM_SCALE < txc->freq)
 			return -EINVAL;
 	}
 
-- 
1.9.1

Re: [PATCH] ntp: Fixup adjtimex freq validation on 32bit systems

[Richard Cochran]

On Tue, Feb 03, 2015 at 10:57:38AM -0800, John Stultz wrote:
> Unfortunately the patch used LONG_MAX/MIN instead of
> LLONG_MAX/MIN, which was fine on 64bit systems, but being
> much smaller on 32bit systems caused false positives
> resulting in most direct frequency adjustments to fail w/
> EINVAL.

...

> One note:
> 0day kbuild bot complains about
> >> kernel/time/ntp.c:637: warning: comparison is always false due to limited range of data type
> >> kernel/time/ntp.c:639: warning: comparison is always false due to limited range of data type
> 
> We could fix this via adding an extra (BITS_PER_LONG == 64)
> case before we check these to avoid it, but that seemed a
> bit too ugly to me. Thoughts?

So the check is 64 bit only?  Might as well mark it like that
explicitly to avoid needless head scratching of 32 bit people.

Thanks,
Richard

[PATCH v2] ntp: Fixup adjtimex freq validation on 32bit systems

[John Stultz]

For tip/timers/urgent.

Additional validation of adjtimex freq values to avoid
potential multiplication overflows were added in commit
5e5aeb4367b (time: adjtimex: Validate the ADJ_FREQUENCY values)

Unfortunately the patch used LONG_MAX/MIN instead of
LLONG_MAX/MIN, which was fine on 64bit systems, but being
much smaller on 32bit systems caused false positives
resulting in most direct frequency adjustments to fail w/
EINVAL.

ntpd only does direct frequency adjustments at startup, so
the issue was not as easily observed there, but other time
sync applications like ptpd and chrony were more effected by
the bug.

See bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=92481
https://bugzilla.redhat.com/show_bug.cgi?id=1188074

This patch changes the checks to use LLONG_MAX for
clarity, and additionally the checks are disabled
on 32bit systems since LLONG_MAX/PPM_SCALE is always
larger then the 32bit long freq value, so mult
overflows aren't possible there.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: stable@vger.kernel.org
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
v2: Included the BITS_PER_LONG check to disable
the check on 32bit systems, since it generates
build warnings in some settings.

 kernel/time/ntp.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 28bf91c..6824ef9 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -633,10 +633,14 @@ int ntp_validate_timex(struct timex *txc)
 	if ((txc->modes & ADJ_SETOFFSET) && (!capable(CAP_SYS_TIME)))
 		return -EPERM;
 
-	if (txc->modes & ADJ_FREQUENCY) {
-		if (LONG_MIN / PPM_SCALE > txc->freq)
+	/*
+	 * Check for potential mult overflows that can
+	 * only happen on 64bit systems.
+	 */
+	if ((txc->modes & ADJ_FREQUENCY) && (BITS_PER_LONG == 64)) {
+		if (LLONG_MIN / PPM_SCALE > txc->freq)
 			return -EINVAL;
-		if (LONG_MAX / PPM_SCALE < txc->freq)
+		if (LLONG_MAX / PPM_SCALE < txc->freq)
 			return -EINVAL;
 	}
 
-- 
1.9.1