1. 30 Nov, 2018 4 commits
  2. 10 Jun, 2018 3 commits
  3. 10 Mar, 2018 4 commits
    • Niko Tyni's avatar
      Releasing 5.20.2-3+deb8u10 to jessie-security · 4a5ebf6b
      Niko Tyni authored
    • Niko Tyni's avatar
      Update changelog · 31c157f2
      Niko Tyni authored
    • Niko Tyni's avatar
      Backport upstream patch for CVE-2018-6913 · 47827ca0
      Niko Tyni authored
    • Tony Cook's avatar
      (perl #131844) fix various space calculation issues in pp_pack.c · c153c205
      Tony Cook authored
      - 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
      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
      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.
      Origin: backport
      Bug: https://rt.perl.org/Public/Bug/Display.html?id=131844
      Patch-Name: fixes/CVE-2018-6913.diff
  4. 17 Sep, 2017 1 commit
  5. 16 Sep, 2017 4 commits
  6. 12 Sep, 2017 2 commits
    • Niko Tyni's avatar
      Update description of base-pm-amends-pt2.diff · d2496990
      Niko Tyni authored
    • Aristotle Pagaltzis's avatar
      Limit dotless-INC effect on base.pm with guard: · 12a52157
      Aristotle Pagaltzis authored
      This introduces a more refined and accurate solution for removing
      '.' from @INC while reducing the false positives.
      The following explanation is roughly what is avaiable in the code
      comments. If you stumble upon this and feel like the commit message
      or the comments are not helpful enough, please introduce another
      commit that adds more explanation or improve the code comments
      (or both).
          if ($INC[-1] eq '.' && %{"$base\::"})
      We decide that:
      The package already exists   => this an optional load
      And: there is a dot at the end of @INC  => we want to hide it
      However: we only want to hide it during our *own* require()
      (i.e. without affecting nested require()s).
      So we add a hook to @INC whose job is to hide the dot, but which
      first checks checks the callstack depth, because within nested
      require()s the callstack is deeper.
      Since CORE::GLOBAL::require makes it unknowable in advance what
      the exact relevant callstack depth will be, we have to record it
      inside a hook. So we put another hook just for that at the front
      of @INC, where it's guaranteed to run -- immediately.
      The dot-hiding hook does its job by sitting directly in front of
      the dot and removing itself from @INC when reached. This causes
      the dot to move up one index in @INC, causing the loop inside
      pp_require() to skip it.
      Loaded coded may disturb this precise arrangement, but that's OK
      because the hook is inert by that time. It is only active during
      the top-level require(), when @INC is in our control. The only
      possible gotcha is if other hooks already in @INC modify @INC in
      some way during that initial require().
      Note that this jiggery hookery works just fine recursively: if
      a module loaded via base.pm uses base.pm itself, there will be
      one pair of hooks in @INC per base::import call frame, but the
      pairs from different nestings do not interfere with each other.
      (cherry picked from commit 571931bfa1120564fe207965f9ec2ea0f8bbbb8a)
      [This is a forward-port, with improved commit message by Sawyer X
      <xsawyerx@cpan.org>, of the commit that was cherry-picked into
      maint-5.22 and maint-5.24 as commits a93da9a38c and 1afa289000
      (cherry picked from commit fa71f6670dda393818d17f2f3bd2bee165347849)
      [ backported to Debian 5.20 by Niko Tyni, patch description from
      Origin: backport, http://perl5.git.perl.org/perl.git/commit/1afa2890005f3acdb5794bc9ec34dfd0a7e54c28
      Patch-Name: debian/CVE-2016-1238/base-pm-amends-pt2.diff
  7. 11 Jul, 2017 1 commit
  8. 08 Jun, 2017 5 commits
  9. 03 Jun, 2017 5 commits
  10. 22 Jul, 2016 11 commits