Em Fri, Aug 23, 2019 at 04:42:47PM -0400, Vince Weaver escreveu: > 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?
> > > 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? Fell thru the cracks, but yeah, I was waiting for a patch, can you send it? - Arnaldo > This is actually an exploitable security bug if you can convince someone > to run "perf" on an untrusted perf.data file. Indeed, and in light of the current discussion about unprivileged eBPF I think we should start dropping privileges in perf report, etc. - Arnaldo
