kernel/time/ntp.c: Possible off-by-one error in TAI range check?

kernel/time/ntp.c: Possible off-by-one error in TAI range check?

[Ondrej Mosnacek]

Hello,

while writing tests for clock adjustment auditing [1] [2], I stumbled
upon a strange behavior of adjtimex(2) when setting the TAI offset...

Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
change the TAI offset from userspace via adjtimex(2). The code checks
if the input value (txc->constant) is greater than 0 and if it is not,
then it doesn't modify the value. Ignoring the fact that this check
should probably be in timekeeping_validate_timex() and cause -EINVAL
to be returned when false, I find it strange that the check doesn't
allow to set the value to 0, which seems to be the default value...

Was this behavior intended or should the code actually check for
txc->constant >= 0 instead of txc->constant > 0?

Thanks,

[1] https://github.com/linux-audit/audit-kernel/issues/10
[2] https://github.com/linux-audit/audit-kernel/wiki/RFE-More-detailed-auditing-of-changes-to-system-clock

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check?

[Ondrej Mosnacek]

On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Hello,
>
> while writing tests for clock adjustment auditing [1] [2], I stumbled
> upon a strange behavior of adjtimex(2) when setting the TAI offset...
>
> Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
> change the TAI offset from userspace via adjtimex(2). The code checks
> if the input value (txc->constant) is greater than 0 and if it is not,
> then it doesn't modify the value. Ignoring the fact that this check
> should probably be in timekeeping_validate_timex() and cause -EINVAL
> to be returned when false, I find it strange that the check doesn't
> allow to set the value to 0, which seems to be the default value...
>
> Was this behavior intended or should the code actually check for
> txc->constant >= 0 instead of txc->constant > 0?

Ping?

>
> Thanks,
>
> [1] https://github.com/linux-audit/audit-kernel/issues/10
> [2] https://github.com/linux-audit/audit-kernel/wiki/RFE-More-detailed-auditing-of-changes-to-system-clock
>
> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Software Engineer, Security Technologies
> Red Hat, Inc.

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check?

[Thomas Gleixner]

On Mon, 15 Apr 2019, Ondrej Mosnacek wrote:

CC+ Miroslav

> On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > Hello,
> >
> > while writing tests for clock adjustment auditing [1] [2], I stumbled
> > upon a strange behavior of adjtimex(2) when setting the TAI offset...
> >
> > Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
> > change the TAI offset from userspace via adjtimex(2). The code checks
> > if the input value (txc->constant) is greater than 0 and if it is not,
> > then it doesn't modify the value. Ignoring the fact that this check
> > should probably be in timekeeping_validate_timex() and cause -EINVAL
> > to be returned when false, I find it strange that the check doesn't
> > allow to set the value to 0, which seems to be the default value...
> >
> > Was this behavior intended or should the code actually check for
> > txc->constant >= 0 instead of txc->constant > 0?
> 
> Ping?
> 
> >
> > Thanks,
> >
> > [1] https://github.com/linux-audit/audit-kernel/issues/10
> > [2] https://github.com/linux-audit/audit-kernel/wiki/RFE-More-detailed-auditing-of-changes-to-system-clock
> >
> > --
> > Ondrej Mosnacek <omosnace at redhat dot com>
> > Software Engineer, Security Technologies
> > Red Hat, Inc.
> 
> -- 
> Ondrej Mosnacek <omosnace at redhat dot com>
> Software Engineer, Security Technologies
> Red Hat, Inc.
> 

Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check?

[Miroslav Lichvar]

On Mon, Apr 15, 2019 at 10:09:43AM +0200, Thomas Gleixner wrote:
> > On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
> > > change the TAI offset from userspace via adjtimex(2). The code checks
> > > if the input value (txc->constant) is greater than 0 and if it is not,
> > > then it doesn't modify the value. Ignoring the fact that this check
> > > should probably be in timekeeping_validate_timex() and cause -EINVAL
> > > to be returned when false, I find it strange that the check doesn't
> > > allow to set the value to 0, which seems to be the default value...
> > >
> > > Was this behavior intended or should the code actually check for
> > > txc->constant >= 0 instead of txc->constant > 0?

I guess zero here means "unknown" and maybe the intention was to not
allow setting the offset to an unknown value once it has been set to a
valid value. The trouble is that after inserting a leap second the
offset may change from zero to one.

I think it should be changed to allow setting the offset to zero.

-- 
Miroslav Lichvar

Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check?

[Thomas Gleixner]

On Mon, 15 Apr 2019, Miroslav Lichvar wrote:
> On Mon, Apr 15, 2019 at 10:09:43AM +0200, Thomas Gleixner wrote:
> > > On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
> > > > change the TAI offset from userspace via adjtimex(2). The code checks
> > > > if the input value (txc->constant) is greater than 0 and if it is not,
> > > > then it doesn't modify the value. Ignoring the fact that this check
> > > > should probably be in timekeeping_validate_timex() and cause -EINVAL
> > > > to be returned when false, I find it strange that the check doesn't
> > > > allow to set the value to 0, which seems to be the default value...
> > > >
> > > > Was this behavior intended or should the code actually check for
> > > > txc->constant >= 0 instead of txc->constant > 0?
> 
> I guess zero here means "unknown" and maybe the intention was to not
> allow setting the offset to an unknown value once it has been set to a
> valid value. The trouble is that after inserting a leap second the
> offset may change from zero to one.
> 
> I think it should be changed to allow setting the offset to zero.

Can someone please send a patch with a coherent changelog?

Thanks,

	tglx