This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
(perl #131844) fix various space calculation issues in pp_pack.c
authorTony Cook <tony@develop-help.com>
Mon, 7 Aug 2017 23:32:58 +0000 (09:32 +1000)
committerTony Cook <tony@develop-help.com>
Mon, 16 Apr 2018 01:49:20 +0000 (11:49 +1000)
commitf17fed5006177dce8ac48229c424a2da0d6ba492
tree1c056fa075840c57430ee606b148c6f3d9d55929
parenta684213360784beeff22665b3da443d7b86e26cc
(perl #131844) fix various space calculation issues in pp_pack.c

- for the originally reported case, if the start/cur pointer is in the
  top 75% of the address space the add (cur) + glen addition would
  overflow, resulting in the condition failing incorrectly.

- the addition of the existing space used to the space needed could
  overflow, resulting in too small an allocation and a buffer overflow.

- the scaling for UTF8 could overflow.

- the multiply to calculate the space needed for many items could
  overflow.

For the first case, do a space calculation without making new pointers.

For the other cases, detect the overflow and croak if there's an
overflow.

Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.

For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.

Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.

One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.
pp_pack.c
t/op/pack.t