Messages in this thread | | | Date | Tue, 16 Dec 2014 13:34:59 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [PATCH] perf tool: Fix use after free in filename__read_build_id |
| |
Em Tue, Dec 16, 2014 at 04:35:23PM +0100, Jiri Olsa escreveu: > On Tue, Dec 16, 2014 at 12:16:12PM +1000, Mitchell Krome wrote: > > In filename__read_build_id, phdr points to memory in buf, which gets realloced > > before a call to fseek that uses phdr->p_offset. This change stores the value > > of p_offset before buf is realloced, so the fseek can use the value safely. > > > > Signed-off-by: Mitchell Krome <mitchellkrome@gmail.com> > > --- > > tools/perf/util/symbol-minimal.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c > > index fa585c6..d7efb03 100644 > > --- a/tools/perf/util/symbol-minimal.c > > +++ b/tools/perf/util/symbol-minimal.c > > @@ -129,6 +129,7 @@ int filename__read_build_id(const char *filename, void *bf, size_t size) > > > > for (i = 0, phdr = buf; i < ehdr.e_phnum; i++, phdr++) { > > void *tmp; > > + long offset; > > > > if (need_swap) { > > phdr->p_type = bswap_32(phdr->p_type); > > @@ -140,12 +141,13 @@ int filename__read_build_id(const char *filename, void *bf, size_t size) > > continue; > > > > buf_size = phdr->p_filesz; > > + offset = phdr->p_offset; > > tmp = realloc(buf, buf_size); > > if (tmp == NULL) > > goto out_free; > > > > buf = tmp; > > - fseek(fp, phdr->p_offset, SEEK_SET); > > + fseek(fp, offset, SEEK_SET); > > so the concern is that the realloc buf_size will be smaller > than the 'buf' offset of phdr->p_offset value, right? Anyway:
at first I got unsure because of what realloc man page says, i.e. the common part will have the same contents, i.e. before and after what is in a a given offset will remain the same if in an area <= new size.
But yeah, if phdr->p_filesz < offsetof(Elf32_Phdr, p_offset) (unlikely, I guess), then accessing phdr->p_offset after the realloc may be unsafe (perhaps when using some off-limits memory access tool that paints freed memory?).
Anyway, the new code is clear and more robust, applying.
> Acked-by: Jiri Olsa <jolsa@kernel.org>
Thanks,
> jirka
| |