29 Dec, 2018

1 commit

  • commit 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 upstream.

    The signal delivery path of posix-timers can try to rearm the timer even if
    the interval is zero. That's handled for the common case (hrtimer) but not
    for alarm timers. In that case the forwarding function raises a division by
    zero exception.

    The handling for hrtimer based posix timers is wrong because it marks the
    timer as active despite the fact that it is stopped.

    Move the check from common_hrtimer_rearm() to posixtimer_rearm() to cure
    both issues.

    Reported-by: syzbot+9d38bedac9cc77b8ad5e@syzkaller.appspotmail.com
    Signed-off-by: Thomas Gleixner
    Cc: John Stultz
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: sboyd@kernel.org
    Cc: stable@vger.kernel.org
    Cc: syzkaller-bugs@googlegroups.com
    Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1812171328050.1880@nanos.tec.linutronix.de
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

04 Oct, 2018

2 commits

  • [ Upstream commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 ]

    The posix timer overrun handling is broken because the forwarding functions
    can return a huge number of overruns which does not fit in an int. As a
    consequence timer_getoverrun(2) and siginfo::si_overrun can turn into
    random number generators.

    The k_clock::timer_forward() callbacks return a 64 bit value now. Make
    k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal
    accounting is correct. 3Remove the temporary (int) casts.

    Add a helper function which clamps the overrun value returned to user space
    via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value
    between 0 and INT_MAX. INT_MAX is an indicator for user space that the
    overrun value has been clamped.

    Reported-by: Team OWL337
    Signed-off-by: Thomas Gleixner
    Acked-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Michael Kerrisk
    Link: https://lkml.kernel.org/r/20180626132705.018623573@linutronix.de
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • [ Upstream commit 6fec64e1c92d5c715c6d0f50786daa7708266bde ]

    The posix timer ti_overrun handling is broken because the forwarding
    functions can return a huge number of overruns which does not fit in an
    int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn
    into random number generators.

    As a first step to address that let the timer_forward() callbacks return
    the full 64 bit value.

    Cast it to (int) temporarily until k_itimer::ti_overrun is converted to
    64bit and the conversion to user space visible values is sanitized.

    Reported-by: Team OWL337
    Signed-off-by: Thomas Gleixner
    Acked-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Michael Kerrisk
    Link: https://lkml.kernel.org/r/20180626132704.922098090@linutronix.de
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

29 Mar, 2018

1 commit

  • commit 19b558db12f9f4e45a22012bae7b4783e62224da upstream.

    The clockid argument of clockid_to_kclock() comes straight from user space
    via various syscalls and is used as index into the posix_clocks array.

    Protect it against spectre v1 array out of bounds speculation. Remove the
    redundant check for !posix_clock[id] as this is another source for
    speculation and does not provide any advantage over the return
    posix_clock[id] path which returns NULL in that case anyway.

    Signed-off-by: Thomas Gleixner
    Acked-by: Peter Zijlstra (Intel)
    Acked-by: Dan Williams
    Cc: Rasmus Villemoes
    Cc: Greg KH
    Cc: stable@vger.kernel.org
    Cc: Linus Torvalds
    Cc: David Woodhouse
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1802151718320.1296@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

20 Dec, 2017

1 commit

  • commit cef31d9af908243421258f1df35a4a644604efbe upstream.

    timer_create() specifies via sigevent->sigev_notify the signal delivery for
    the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD
    and (SIGEV_SIGNAL | SIGEV_THREAD_ID).

    The sanity check in good_sigevent() is only checking the valid combination
    for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is
    not set it accepts any random value.

    This has no real effects on the posix timer and signal delivery code, but
    it affects show_timer() which handles the output of /proc/$PID/timers. That
    function uses a string array to pretty print sigev_notify. The access to
    that array has no bound checks, so random sigev_notify cause access beyond
    the array bounds.

    Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
    masking from various code pathes as SIGEV_NONE can never be set in
    combination with SIGEV_THREAD_ID.

    Reported-by: Eric Biggers
    Reported-by: Dmitry Vyukov
    Reported-by: Alexey Dobriyan
    Signed-off-by: Thomas Gleixner
    Cc: John Stultz
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

30 Jun, 2017

3 commits

  • Usage of these apis and their compat versions makes
    the syscalls: timer_settime and timer_gettime and their
    compat implementations simpler.

    This patch also serves as a preparatory patch for changing
    syscalls to use new time_t data types to support the
    y2038 effort by isolating the processing of user pointers
    through these apis.

    Signed-off-by: Deepa Dinamani
    Signed-off-by: Al Viro

    Deepa Dinamani
     
  • Usage of these apis and their compat versions makes
    the syscalls: clock_nanosleep and nanosleep and
    their compat implementations simpler.

    This is a preparatory patch to isolate data conversions to
    struct timespec64 at userspace boundaries. This helps contain
    the changes needed to transition to new y2038 safe types.

    Signed-off-by: Deepa Dinamani
    Signed-off-by: Al Viro

    Deepa Dinamani
     
  • Usage of these apis and their compat versions makes
    the syscalls: clock_gettime, clock_settime, clock_getres
    and their compat implementations simpler.

    This is a preparatory patch to isolate data conversions to
    struct timespec64 at userspace boundaries. This helps contain
    the changes needed to transition to new y2038 safe types.

    Signed-off-by: Deepa Dinamani
    Signed-off-by: Al Viro

    Deepa Dinamani
     

14 Jun, 2017

10 commits


13 Jun, 2017

2 commits

  • The recent rework of the posix timer internals broke the magic posix
    mechanism, which requires that relative timers are not affected by
    modifications of the underlying clock. That means relative CLOCK_REALTIME
    timers cannot use CLOCK_REALTIME, because that can be set and adjusted. The
    underlying hrtimer switches the clock for these timers to CLOCK_MONOTONIC.

    That still works, but reading the remaining time of such a timer has been
    broken in the rework. The old code used the hrtimer internals directly and
    avoided the posix clock callbacks. Now common_timer_get() uses the
    underlying kclock->timer_get() callback, which is still CLOCK_REALTIME
    based. So the remaining time of such a timer is calculated against the
    wrong time base.

    Handle it by switching the k_itimer->kclock pointer according to the
    resulting hrtimer mode. k_itimer->it_clock still contains CLOCK_REALTIME
    because the timer might be set with ABSTIME later and then it needs to
    switch back to the realtime posix clock implementation.

    Fixes: eae1c4ae275f ("posix-timers: Make use of cancel/arm callbacks")
    Reported-by: Andrei Vagin
    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: John Stultz
    Cc: Cyrill Gorcunov
    Link: http://lkml.kernel.org/r/20170609201156.GB21491@outlook.office365.com

    Thomas Gleixner
     
  • The recent posix timer rework moved the clearing of the itimerspec to the
    real syscall implementation, but forgot that the kclock->timer_get() is
    used by timer_settime() as well. That results in an uninitialized variable
    and bogus values returned to user space.

    Add the missing memset to timer_settime().

    Fixes: eabdec043853 ("posix-timers: Zero settings value in common code")
    Reported-by: Andrei Vagin
    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: John Stultz
    Cc: Cyrill Gorcunov
    Link: http://lkml.kernel.org/r/20170609201156.GB21491@outlook.office365.com

    Thomas Gleixner
     

12 Jun, 2017

1 commit

  • The refactoring of the posix-timer core to allow better code sharing
    introduced inverted logic vs. SIGEV_NONE timers in common_timer_get().

    That causes hrtimer_forward() to be called on active timers, which
    rightfully triggers the warning hrtimer_forward().

    Make sig_none what it says: signal mode == SIGEV_NONE.

    Fixes: 91d57bae0868 ("posix-timers: Make use of forward/remaining callbacks")
    Reported-by: Ye Xiaolong
    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: John Stultz
    Link: http://lkml.kernel.org/r/20170609104457.GA39907@inn.lkp.intel.com

    Thomas Gleixner
     

04 Jun, 2017

13 commits


27 May, 2017

1 commit

  • There are no more modular users providing a posix clock. The register
    function is now pointless so the posix clock array can be initialized
    statically at compile time and the array including the various k_clock
    structs can be marked 'const'.

    Inspired by changes in the Grsecurity patch set, but done proper.

    [ tglx: Massaged changelog and fixed the POSIX_TIMER=n case ]

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Thomas Gleixner
    Cc: Mike Travis
    Cc: Dimitri Sivanich
    Link: http://lkml.kernel.org/r/20170526090311.3377-3-hch@lst.de

    Christoph Hellwig
     

15 Apr, 2017

5 commits

  • struct timespec is not y2038 safe on 32 bit machines. Replace uses of
    struct timespec with struct timespec64 in the kernel.

    The syscall interfaces themselves will be changed in a separate series.

    Note that the restart_block parameter for nanosleep has also been left
    unchanged and will be part of syscall series noted above.

    Signed-off-by: Deepa Dinamani
    Cc: y2038@lists.linaro.org
    Cc: john.stultz@linaro.org
    Cc: arnd@arndb.de
    Link: http://lkml.kernel.org/r/1490555058-4603-8-git-send-email-deepa.kernel@gmail.com
    Signed-off-by: Thomas Gleixner

    Deepa Dinamani
     
  • struct timespec is not y2038 safe on 32 bit machines. Replace uses of
    struct timespec with struct timespec64 in the kernel.

    struct itimerspec internally uses struct timespec. Use struct itimerspec64
    which uses struct timespec64.

    The syscall interfaces themselves will be changed in a separate series.

    Signed-off-by: Deepa Dinamani
    Cc: y2038@lists.linaro.org
    Cc: john.stultz@linaro.org
    Cc: arnd@arndb.de
    Link: http://lkml.kernel.org/r/1490555058-4603-7-git-send-email-deepa.kernel@gmail.com
    Signed-off-by: Thomas Gleixner

    Deepa Dinamani
     
  • struct timespec is not y2038 safe on 32 bit machines. Replace uses of
    struct timespec with struct timespec64 in the kernel.

    The syscall interfaces themselves will be changed in a separate series.

    Signed-off-by: Deepa Dinamani
    Cc: y2038@lists.linaro.org
    Cc: john.stultz@linaro.org
    Cc: arnd@arndb.de
    Link: http://lkml.kernel.org/r/1490555058-4603-6-git-send-email-deepa.kernel@gmail.com
    Signed-off-by: Thomas Gleixner

    Deepa Dinamani
     
  • struct timespec is not y2038 safe on 32 bit machines. Replace uses of
    struct timespec with struct timespec64 in the kernel. The syscall
    interfaces themselves will be changed in a separate series.

    The clock_getres() interface has also been changed to use timespec64 even
    though this particular interface is not affected by the y2038 problem. This
    helps verification for internal kernel code for y2038 readiness by getting
    rid of time_t/ timeval/ timespec completely.

    Signed-off-by: Deepa Dinamani
    Cc: y2038@lists.linaro.org
    Cc: john.stultz@linaro.org
    Cc: arnd@arndb.de
    Link: http://lkml.kernel.org/r/1490555058-4603-5-git-send-email-deepa.kernel@gmail.com
    Signed-off-by: Thomas Gleixner

    Deepa Dinamani
     
  • struct timespec is not y2038 safe on 32 bit machines. Replace uses of
    struct timespec with struct timespec64 in the kernel.

    The syscall interfaces themselves will be changed in a separate series.

    Signed-off-by: Deepa Dinamani
    Cc: y2038@lists.linaro.org
    Cc: john.stultz@linaro.org
    Cc: arnd@arndb.de
    Link: http://lkml.kernel.org/r/1490555058-4603-4-git-send-email-deepa.kernel@gmail.com
    Signed-off-by: Thomas Gleixner

    Deepa Dinamani