On Fri, 26 Jul 2019, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 23, 2019 at 04:42:30PM -0400, Vince Weaver escreveu: > > my perf_tool_fuzzer has found another issue, this one a buffer overflow > > in perf_header__read_build_ids. The build id filename is read in with a > > filename length read from the perf.data file, but this can be longer than > > PATH_MAX which will smash the stack. > > > > This might not be the right fix, not sure if filename should be NUL > > terminated or not. > > > > Signed-off-by: Vince Weaver <[email protected]> > > > > diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c > > index c24db7f4909c..9a893a26e678 100644 > > --- a/tools/perf/util/header.c > > +++ b/tools/perf/util/header.c > > @@ -2001,6 +2001,9 @@ static int perf_header__read_build_ids(struct > > perf_header *header, > > perf_event_header__bswap(&bev.header); > > > > len = bev.header.size - sizeof(bev); > > + > > + if (len>PATH_MAX) len=PATH_MAX; > > + > > Humm, I wonder if we shouldn't just declare the whole file invalid like > you did with the previous patch? > > - Arnaldo > > > if (readn(input, filename, len) != len) > > goto out; > > /* did we ever decide how to fix this issue? Or were you waiting on a followup patch from me?
This is actually an exploitable security bug if you can convince someone to run "perf" on an untrusted perf.data file. Vince
