1. 25 Jan, 2019 1 commit
  2. 22 Jan, 2019 1 commit
  3. 05 Jul, 2018 1 commit
    • delta: fix overflow when computing limit · e087c0de
      When checking whether a delta base offset and length fit into the base
      we have in memory already, we can trigger an overflow which breaks the
      check. This would subsequently result in us reading memory from out of
      bounds of the base.
      
      The issue is easily fixed by checking for overflow when adding `off` and
      `len`, thus guaranteeting that we are never indexing beyond `base_len`.
      This corresponds to the git patch 8960844a7 (check patch_delta bounds
      more carefully, 2006-04-07), which adds these overflow checks.
      
      Reported-by: Riccardo Schirone <rschiron@redhat.com>
      Patrick Steinhardt committed
  4. 29 Jun, 2018 2 commits
    • delta: fix out-of-bounds read of delta · 24597812
      When computing the offset and length of the delta base, we repeatedly
      increment the `delta` pointer without checking whether we have advanced
      past its end already, which can thus result in an out-of-bounds read.
      Fix this by repeatedly checking whether we have reached the end. Add a
      test which would cause Valgrind to produce an error.
      
      Reported-by: Riccardo Schirone <rschiron@redhat.com>
      Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
      Patrick Steinhardt committed
    • delta: fix sign-extension of big left-shift · 7db25870
      Our delta code was originally adapted from JGit, which itself adapted it
      from git itself. Due to this heritage, we inherited a bug from git.git
      in how we compute the delta offset, which was fixed upstream in
      48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
      explained by Linus:
      
          Shifting 'unsigned char' or 'unsigned short' left can result in sign
          extension errors, since the C integer promotion rules means that the
          unsigned char/short will get implicitly promoted to a signed 'int' due to
          the shift (or due to other operations).
      
          This normally doesn't matter, but if you shift things up sufficiently, it
          will now set the sign bit in 'int', and a subsequent cast to a bigger type
          (eg 'long' or 'unsigned long') will now sign-extend the value despite the
          original expression being unsigned.
      
          One example of this would be something like
      
                  unsigned long size;
                  unsigned char c;
      
                  size += c << 24;
      
          where despite all the variables being unsigned, 'c << 24' ends up being a
          signed entity, and will get sign-extended when then doing the addition in
          an 'unsigned long' type.
      
          Since git uses 'unsigned char' pointers extensively, we actually have this
          bug in a couple of places.
      
      In our delta code, we inherited such a bogus shift when computing the
      offset at which the delta base is to be found. Due to the sign extension
      we can end up with an offset where all the bits are set. This can allow
      an arbitrary memory read, as the addition in `base_len < off + len` can
      now overflow if `off` has all its bits set.
      
      Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
      integer again. Add a test with a crafted delta that would actually
      succeed with an out-of-bounds read in case where the cast wouldn't
      exist.
      
      Reported-by: Riccardo Schirone <rschiron@redhat.com>
      Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
      Patrick Steinhardt committed
  5. 29 Dec, 2016 1 commit
  6. 26 May, 2016 2 commits
  7. 13 Feb, 2015 3 commits
  8. 08 Dec, 2013 1 commit
  9. 27 May, 2013 1 commit
  10. 08 Jan, 2013 1 commit
  11. 07 Jan, 2013 1 commit
  12. 27 Nov, 2012 1 commit
  13. 09 Oct, 2012 1 commit