3.2.93-rc1 review patch. If anyone has any objections, please let me know.
------------------ From: Thomas Gleixner <[email protected]> commit f4781e76f90df7aec400635d73ea4c35ee1d4765 upstream. Andrey reported a alartimer related RCU stall while fuzzing the kernel with syzkaller. The reason for this is an overflow in ktime_add() which brings the resulting time into negative space and causes immediate expiry of the timer. The following rearm with a small interval does not bring the timer back into positive space due to the same issue. This results in a permanent firing alarmtimer which hogs the CPU. Use ktime_add_safe() instead which detects the overflow and clamps the result to KTIME_SEC_MAX. Reported-by: Andrey Konovalov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: syzkaller <[email protected]> Cc: John Stultz <[email protected]> Cc: Dmitry Vyukov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [bwh: Backported to 3.2: drop change in alarm_start_relative()] Signed-off-by: Ben Hutchings <[email protected]> --- --- a/kernel/time/alarmtimer.c +++ b/kernel/time/alarmtimer.c @@ -419,7 +419,7 @@ u64 alarm_forward(struct alarm *alarm, k overrun++; } - alarm->node.expires = ktime_add(alarm->node.expires, interval); + alarm->node.expires = ktime_add_safe(alarm->node.expires, interval); return overrun; } @@ -604,7 +604,7 @@ static int alarm_timer_set(struct k_itim ktime_t now; now = alarm_bases[timr->it.alarm.alarmtimer.type].gettime(); - exp = ktime_add(now, exp); + exp = ktime_add_safe(now, exp); } alarm_start(&timr->it.alarm.alarmtimer, exp);
