On Fri, Jan 18, 2019 at 8:18 AM Tom de Vries <tdevr...@suse.de> wrote:
>
> On 18-01-19 16:40, Ian Lance Taylor wrote:
> > int
> > backtrace_get_view (struct backtrace_state *state ATTRIBUTE_UNUSED,
> > - int descriptor, off_t offset, size_t size,
> > + int descriptor, off_t offset, uint64_t size,
> > backtrace_error_callback error_callback,
> > void *data, struct backtrace_view *view)
> > {
> > @@ -60,6 +60,12 @@ backtrace_get_view (struct backtrace_sta
> > off_t pageoff;
> > void *map;
> >
> > + if ((uint64_t) (size_t) size != size)
> > + {
> > + error_callback (data, "file size too large", 0);
> > + return 0;
> > + }
> > +
>
> Agreed, this will fix the PR.
Thanks. Committed to mainline.
> There's a cornercase I'm not sure is worth bothering about, but given
> that this is an RFC: in the case of 32-bit systems with 32-bit
> filesystem, there will be a range of numbers that fit in size_t, but are
> too large for off_t (both 32-bit but size_t unsigned and off_t signed),
> so in that case, the file size is too large, but we're not detecting
> that here. Though I think that should be handled in the subsequent mmap
> (or, in the case of read.c, in the subsequent read(), though I'm
> guessing the earlier backtrace_alloc > 2GB will already fail).
Yeah, I'm not worried about that case. A system with a signed 32-bit
off_t can't really support files larger than 2G anyhow, since for
larger files the struct stat st_size field will be negative.
Ian
