On Mon Jul 11 11:47:03 2011, meyering wrote:
> I first noticed this using Fedora 15's perl-5.12.4-159.fc15.x86_64,
> but reproduced (below) using the latest built from git on the maint-
> 5.12
> branch.
>
> Using a large string repeat count makes perl overrun a heap buffer:
>
> $ ./perl -le 'print "v"x(2**31+1)'
> [Exit 139 (SEGV)]
>
> If you use an approx. doubled count (s/31/32), you can make Perl
> fail to initialize a 4GiB buffer and then proceed to write all of
> that uninitialized data to output:
>
> $ ./perl -le 'print "v"x(2**32+1)' > out
> ("out" starts with "v", and the following 4GiB are from
> uninitialized heap)
>
> Why? Because the caller of Perl_repeatcpy uses a type of IV
> for the "count" variable corresponding to our counts, while
> Perl_repeatcpy itself uses the narrower type of I32.
> When you pass "count - 1" to Perl_repeatcpy you get INT_MIN
> in the first case, and 0 in the second.
> Passing INT_MIN as the count here,
>
> util.c:3037: memset(to, *from, count);
>
> sign-extends to SIZE_MAX, and no one has that much memory,
> so the memset scribbles well beyond the "to" buffer.
>
> As for fixing it, I've included a patch that works for me, but it's
> probably not so simple. I doubt you can so easily change a public API
> like Perl_repeatcpy, even if it's so fundamentally limited. Besides,
> if you want to fix this, I suspect that this is just one manifestation
> of a larger problem. For example, what if the string itself has
> length
> larger than INT_MAX? Same problem, maybe, since the "len" parameter
> also has type I32.
>
> -- >8 --
> Subject: [PATCH] don't segfault given string repeat count larger than
> 2^31
Thank you. Applied as 26e1303d6.
Thread Next