Prev: [PATCH v2] trace-cmd: prevent print_graph_duration buffer overflow
Next: pci: Don't enable aspm before drivers have had a chance to veto it
From: Steven Rostedt on 15 Jun 2010 11:00 Quick note. Please send to my rostedt(a)goodmis.org address. I may not see messages here for weeks at a time. I author patches with my RH account just to "advertise" who I work for. But I sign-off-by with the account I want people to send to. On Tue, 2010-06-15 at 10:47 -0400, Chase Douglas wrote: > Passing n > sizeof(string) to snprintf can cause a glibc buffer overflow > condition. We know the exact size of nsecs_str, so use it along with the > the math to determine the longest string size we want. > > Note that an overflow isn't really possible given the format of the > string. However, glibc would abort due to a runtime check. > > Signed-off-by: Chase Douglas <chase.douglas(a)canonical.com> Thanks! Can you write a similar patch for the Linux kernel too. It may need to go to stable as well. -- Steve > --- > trace-ftrace.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/trace-ftrace.c b/trace-ftrace.c > index af9ac8d..181a00f 100644 > --- a/trace-ftrace.c > +++ b/trace-ftrace.c > @@ -21,6 +21,7 @@ > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > +#include <sys/param.h> > > #include "trace-cmd.h" > > @@ -148,7 +149,7 @@ static void print_graph_duration(struct trace_seq *s, unsigned long long duratio > > /* 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, MIN(sizeof(nsecs_str), 8 - len), "%03lu", nsecs_rem); > trace_seq_printf(s, ".%s", nsecs_str); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chase Douglas on 15 Jun 2010 11:30 On Tue, 2010-06-15 at 10:54 -0400, Steven Rostedt wrote: > Quick note. Please send to my rostedt(a)goodmis.org address. I may not see > messages here for weeks at a time. I author patches with my RH account > just to "advertise" who I work for. But I sign-off-by with the account I > want people to send to. Ahh. I took the email address from the authors line like you said :). Is this standard practice for others as well? > On Tue, 2010-06-15 at 10:47 -0400, Chase Douglas wrote: > > Passing n > sizeof(string) to snprintf can cause a glibc buffer overflow > > condition. We know the exact size of nsecs_str, so use it along with the > > the math to determine the longest string size we want. > > > > Note that an overflow isn't really possible given the format of the > > string. However, glibc would abort due to a runtime check. > > > > Signed-off-by: Chase Douglas <chase.douglas(a)canonical.com> > > Thanks! > > Can you write a similar patch for the Linux kernel too. It may need to > go to stable as well. Sure -- Chase -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 15 Jun 2010 11:40
On Tue, 2010-06-15 at 11:21 -0400, Chase Douglas wrote: > On Tue, 2010-06-15 at 10:54 -0400, Steven Rostedt wrote: > > Quick note. Please send to my rostedt(a)goodmis.org address. I may not see > > messages here for weeks at a time. I author patches with my RH account > > just to "advertise" who I work for. But I sign-off-by with the account I > > want people to send to. > > Ahh. I took the email address from the authors line like you said :). Is > this standard practice for others as well? Probably not, but I like to confuse people ;-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |