--- /dev/null
+From 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Fri, 7 Dec 2007 19:16:17 +0100
+Subject: hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/kernel/hrtimer.c
++++ b/kernel/hrtimer.c
+@@ -826,6 +826,14 @@ hrtimer_start(struct hrtimer *timer, kti
+ #ifdef CONFIG_TIME_LOW_RES
+ tim = ktime_add(tim, base->resolution);
+ #endif
++ /*
++ * Careful here: User space might have asked for a
++ * very long sleep, so the add above might result in a
++ * negative number, which enqueues the timer in front
++ * of the queue.
++ */
++ if (tim.tv64 < 0)
++ tim.tv64 = KTIME_MAX;
+ }
+ timer->expires = tim;
+