All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Steven Rostedt <srostedt@redhat.com>,
	Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] trace-cmd: prevent print_graph_duration buffer overflow
Date: Tue, 15 Jun 2010 15:10:03 +0200	[thread overview]
Message-ID: <20100615131002.GD5342@nowhere> (raw)
In-Reply-To: <1276607098.3452.5.camel@cndougla-ubuntu>

On Tue, Jun 15, 2010 at 09:04:58AM -0400, Chase Douglas wrote:
> On Tue, 2010-06-15 at 14:49 +0200, Frederic Weisbecker wrote:
> > On Mon, Jun 14, 2010 at 08:16:03PM -0400, Steven Rostedt wrote:
> > > On Mon, 2010-06-14 at 17:40 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > > On Sun, 13 Jun 2010 17:01:34 EDT, Chase Douglas said:
> > > > > On Sun, 2010-06-13 at 16:52 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > > > > On Sun, 13 Jun 2010 13:11:48 EDT, Chase Douglas said:
> > > > > > > Passing n > sizeof(string) to snprintf can cause a glibc buffer overflow
> > > > > > > condition. We know the exact size of nsecs_str, so use it instead of
> > > > > > > math that may overflow.
> > > > > > 
> > > > > > >  	/* Print nsecs (we don't want to exceed 7 numbers) */
> > > > > > >  	if ((s->len - len) < 7) {
> > > > > > > -		snprintf(nsecs_str, 8 - (s->len - len), "%03lu", nsecs_rem);
> > > > > > > +		snprintf(nsecs_str, sizeof(nsecs_str), "%03lu", nsecs_rem);
> > > > > > 
> > > > > > We only get into this code after we've checked that the length is under 7
> > > > > > characters.  How much overflow can happen as long as the sizeof(nsecs_str) is a
> > > > > > sane size (like at least 8 chars)?  Probably a better bet would be doing the
> > > > > > right thing and 'BUILD_BUG_ON(sizeof(nsecs_str) < 8);'?
> > > > > 
> > > > > nsecs_str is a local variable defined just above this block of code as:
> > > > > 
> > > > > 	char nsecs_str[5];
> > > > > 
> > > > > I was hitting cases where s->len == 64 and len == 63, leading to the
> > > > > size argument of snprintf being 7 on a 5 byte string. I didn't delve too
> > > > > much into the reasoning for the if statement, but I think it's math is
> > > > > not actually related to the size of nsecs_rem but to some other string
> > > > > length.
> > > > 
> > > > This is starting to smell like that patch is just papering over a bug...
> > > > 
> > > > I saw that '8 -' and made the rash assumption that was the size of the array.
> > > > Is 5 in fact big enough and the  's->len - len' calculation is broken, or
> > > > should it be bigger?  As you noted, that length calculation is looking a tad
> > > > sketchy.  (And if we're stuck with '5' because it's a magic number for
> > > > somebody's formatting purposes, maybe it needs to be a #define?)
> > > > 
> > > 
> > > Ouch, this is worse than that. this code was cut & pasted almost
> > > directly from the Linux kernel (kernel/trace/trace_function_graph.c).
> > > And it looks like any bug here is also a bug there. The difference is
> > > that if we trigger the bug there we crash the kernel :-p
> > 
> > 
> > I must be missing the purpose of this patch.
> > 
> > log10(nsecs_rem) can't exceed 3 characters as it is the rest of
> > a division per 1000.
> > 
> > The goal of this:
> > 
> > 	if (len < 7) {
> > 		snprintf(nsecs_str, 8 - len, "%03lu", nsecs_rem)
> > 
> > is to avoid having a duration that exceeds 7 characters, so formatted nsecs
> > be shrinked on need.
> > 
> > For example:
> > 
> > 	75000.567
> > 
> > would be shrinked to 75000.56, and that's the point.
> > 
> > if (len < 7) is not a security guard, it is a formatting convenience
> > to get a fixed column length.
> > 
> > The security guard is the mathematics that tells us log10(n % 1000) < 4.
> > In fact nsecs_str could be even of size 4 rather than 5.
> 
> I agree that there is no *real* security issue here because of the
> length of the string that snprintf would generate. However, glibc still
> barfs when you pass in a size parameter larger than the string. Without
> this patch, trace-cmd is unusable for me; glibc aborts as soon as the
> condition is hit. I found this as I was packaging trace-cmd for Ubuntu,
> so maybe glibc in other distributions is behaving differently?


Ah, I see what you mean. So the check is made on runtime, right?
But your patch breaks the nsec adaptive size reduction that keeps a fixed
column size.

What about:

	if (len < 7) {
-		snprintf(nsecs_str, 8 - len, "%03lu", nsecs_rem);
+		snprintf(nsecs_str, min(sizeof(nsecs_rem), 8 - len), "%03lu", nsecs_rem);


  reply	other threads:[~2010-06-15 13:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-13 17:11 [PATCH] trace-cmd: append to CFLAGS instead of being overriden Chase Douglas
2010-06-13 17:11 ` [PATCH] trace-cmd: prevent print_graph_duration buffer overflow Chase Douglas
2010-06-13 20:52   ` Valdis.Kletnieks
2010-06-13 21:01     ` Chase Douglas
2010-06-14 21:40       ` Valdis.Kletnieks
2010-06-15  0:16         ` Steven Rostedt
2010-06-15 12:49           ` Frederic Weisbecker
2010-06-15 13:04             ` Chase Douglas
2010-06-15 13:10               ` Frederic Weisbecker [this message]
2010-06-15 13:20                 ` Chase Douglas

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=20100615131002.GD5342@nowhere \
    --to=fweisbec@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=chase.douglas@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srostedt@redhat.com \
    /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.