hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)
commit3e96745119d46a80b044b72634169621fc814dde
authorThomas Gleixner <tglx@linutronix.de>
Fri, 7 Dec 2007 18:16:17 +0000 (7 19:16 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 14 Dec 2007 18:31:56 +0000 (14 10:31 -0800)
treec481309c34883be6a190ba127768c2498166344b
parent909633b01897ae2cc689e1ab25c697fc11ceb6e8
hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)

patch 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 in mainline

Relative hrtimers with a large timeout value might end up as negative
timer values, when the current time is added in hrtimer_start().

This in turn is causing the clockevents_set_next() function to set an
huge timeout and sleep for quite a long time when we have a clock
source which is capable of long sleeps like HPET. With PIT this almost
goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code
sorts this out in the next timer interrupt, so we never noticed that
problem which has been there since the first day of hrtimers.

This bug became more apparent in 2.6.24 which activates HPET on more
hardware.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/hrtimer.c