All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>,
	Johannes Bauer <JohannesBauer@gmx.de>,
	linux-kernel@vger.kernel.org, schwab@suse.de,
	Stable Kernel Team <stable@kernel.org>, Greg KH <greg@kroah.com>,
	Adrian Bunk <bunk@stusta.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] hrtimer: prevent overrun DoS in hrtimer_forward()
Date: Fri, 16 Mar 2007 22:05:20 +0100	[thread overview]
Message-ID: <1174079120.13341.286.camel@localhost.localdomain> (raw)
In-Reply-To: <20070316124313.9f0afc05.akpm@linux-foundation.org>

On Fri, 2007-03-16 at 12:43 -0800, Andrew Morton wrote:
> On Wed, 14 Mar 2007 11:00:12 +0100 Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > rtimer_forward() does not check for the possible overflow of
> > timer->expires. This can happen on 64 bit machines with large interval
> > values and results currently in an endless loop in the softirq because
> > the expiry value becomes negative and therefor the timer is expired all
> > the time.
> > 
> > Check for this condition and set the expiry value to the max. expiry
> > time in the future.
> > 
> > The fix should be applied to stable kernel series as well.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix,de>
> > 
> > diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> > index ec4cb9f..5e7122d 100644
> > --- a/kernel/hrtimer.c
> > +++ b/kernel/hrtimer.c
> > @@ -644,6 +644,12 @@ hrtimer_forward(struct hrtimer *timer, k
> >  		orun++;
> >  	}
> >  	timer->expires = ktime_add(timer->expires, interval);
> > +	/*
> > +	 * Make sure, that the result did not wrap with a very large
> > +	 * interval.
> > +	 */
> > +	if (timer->expires.tv64 < 0)
> > +		timer->expires = ktime_set(KTIME_SEC_MAX, 0);
> >  
> >  	return orun;
> >  }
> 
> kernel/hrtimer.c: In function 'hrtimer_forward':
> kernel/hrtimer.c:652: warning: overflow in implicit constant conversion
> 
> problem is, KTIME_SEC_MAX is 9,223,372,036 and ktime_set() takes a `long'.

Stupid me :(

> This?
> 
> --- a/include/linux/ktime.h~ktime_set-fix-arg-type
> +++ a/include/linux/ktime.h
> @@ -72,13 +72,13 @@ typedef union {
>   *
>   * Return the ktime_t representation of the value
>   */
> -static inline ktime_t ktime_set(const long secs, const unsigned long nsecs)
> +static inline ktime_t ktime_set(const s64 secs, const unsigned long nsecs)
>  {
>  #if (BITS_PER_LONG == 64)
>  	if (unlikely(secs >= KTIME_SEC_MAX))
>  		return (ktime_t){ .tv64 = KTIME_MAX };
>  #endif
> -	return (ktime_t) { .tv64 = (s64)secs * NSEC_PER_SEC + (s64)nsecs };
> +	return (ktime_t) { .tv64 = secs * NSEC_PER_SEC + (s64)nsecs };
>  }
>  
>  /* Subtract two ktime_t variables. rem = lhs -rhs: */
> _
> 
> I worry about that `secs >= KTIME_SEC_MAX' comparison in there, too.  Both
> operands are signed.

I'd prefer this one: The maximum seconds value we can handle on 32bit is
LONG_MAX.

diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index c68c7ac..248305b 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -57,7 +57,11 @@ typedef union {
 } ktime_t;
 
 #define KTIME_MAX			((s64)~((u64)1 << 63))
-#define KTIME_SEC_MAX			(KTIME_MAX / NSEC_PER_SEC)
+#if (BITS_PER_LONG == 64)
+# define KTIME_SEC_MAX			(KTIME_MAX / NSEC_PER_SEC)
+#else
+# define KTIME_SEC_MAX			LONG_MAX
+#endif
 
 /*
  * ktime_t definitions when using the 64-bit scalar representation:



  reply	other threads:[~2007-03-16 21:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13 18:55 x86_64 system lockup from userspace using setitimer() Johannes Bauer
2007-03-13 19:19 ` Andreas Schwab
2007-03-13 20:02 ` Chuck Ebbert
2007-03-13 20:33   ` Thomas Gleixner
2007-03-14 10:00     ` [PATCH] hrtimer: prevent overrun DoS in hrtimer_forward() Thomas Gleixner
2007-03-14 10:08       ` Ingo Molnar
2007-03-16 20:43       ` Andrew Morton
2007-03-16 21:05         ` Thomas Gleixner [this message]
2007-03-18 21:16           ` Chuck Ebbert
2007-03-18 21:32             ` Thomas Gleixner
2007-03-18 21:53               ` Chuck Ebbert
2007-03-18 22:04                 ` Thomas Gleixner
2007-03-18 22:02                   ` Chuck Ebbert
2007-04-04 21:11       ` Adrian Bunk
2007-04-04 21:30         ` Thomas Gleixner
2007-04-09 13:01           ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1174079120.13341.286.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=JohannesBauer@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@stusta.de \
    --cc=cebbert@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=schwab@suse.de \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.