develooper Front page | perl.perl5.porters | Postings from February 2015

[perl #123554] 7-byte file causes Perl 5.21.8 to segfault

From:
Tony Cook via RT
Date:
February 9, 2015 23:46
Subject:
[perl #123554] 7-byte file causes Perl 5.21.8 to segfault
Message ID:
rt-4.0.18-21186-1423525594-459.123554-15-0@perl.org
On Sun Jan 18 20:48:57 2015, tonyc wrote:
> On Tue Jan 06 16:23:36 2015, tonyc wrote:
> > On Mon Jan 05 21:58:35 2015, tonyc wrote:
> > > On Mon Jan 05 20:24:11 2015, brian.carpenter@gmail.com wrote:
> > > > I'm still fuzzing a Perl binary that I built from git source on
> > > > 01/02/2015
> > > > using the afl-gcc (http://lcamtuf.coredump.cx/afl/) compiler:
> > > >
> > > > CC=/path/to/afl-gcc ./Configure
> > > > AFL_HARDEN=1 make
> > >
> > > This doesn't need afl-gcc to reproduce:
> > >
> > > $ ./perl -e '33x~3'
> > > Segmentation fault
> > >
> > > This is caused by pp_repeat passing ((size_t)~0) to SvGROW() and then
> > > Perl_sv_grow() bumps that up by 1 (per cbcb2a1) to allocate a byte
> > > for
> > > a COW count.  Unfortunately ((size_t)~0)+1 is 0, so Perl_sv_grow()
> > > does nothing, and the string is repeated into the original buffer.
> > >
> > > The following prevents the segfault and produces the expected panic
> > > instead...
> > 
> > I've attached a format-patch patch instead, which directly checks
> > against MEM_SIZE_MAX instead, rather than checking for the overflow.
> > 
> > I considered making the comparison C<< newlen < MEM_SIZE_MAX >>
> > instead, which produced the same code, in case (somehow!)
> > MEM_SIZE/STRLEN/Size_t ended up signed, but since that would break
> > MEM_SIZE_MAX anyway I though it would be slightly more confusing.
> > 
> > As to the test, since we're allocating (address_space_size-1) bytes,
> > the result creation should fail before any memory is allocated, so
> > this isn't going to cause smokers (or other perl test runs) to attempt
> > to allocate stupidly large amounts of space.
> 
> Applied as fa8f4f85ec35b0f047603e5b90a788571f7141bd.

With jhi's help, fixed a couple of other size overflows in 9efda33a86bb90e4838144d230a4fc3ae4d63d7d.

Unfortunately, which perl isn't segfaulting, in some builds this falls back to the out of memory handler, which can't be caught by eval, so remove the test.

Tony

---
via perlbug:  queue: perl5 status: resolved
https://rt.perl.org/Ticket/Display.html?id=123554



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About