Re: [PATCH] perf tool: Fix use after free in filename__read_build_id

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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