1. 05 Jun, 2022 2 commits
    • Jacob Boerema's avatar
      app: check for invalid offsets when loading XCF files · 74495943
      Jacob Boerema authored
      More safety checks for detecting broken xcf files, also based on examining
      issue #8230.
      
      After reading an offset where layer, channel, etc. data is stored, we
      add a check to make sure that offset is not before where we read the
      offset value. Because the data is always written after the offset that
      points to it.
      
      (cherry picked from commit a8428692)
      74495943
    • Jacob Boerema's avatar
      app: check max dimensions when loading xcf files · e7d4b580
      Jacob Boerema authored
      Improvements in loading broken xcf files, based on examining issue #8230.
      Besides checking for a minimum width and height, GIMP also has a maximum
      size we can and should check.
      
      In the case of the image itself, we change invalid dimensions to a size of
      1 in hope that the individual layers etc will have the correct size.
      For layer, we will also try to go on, but for channel and layer mask, we
      will give up.
      
      (cherry picked from commit 24c962b9)
      e7d4b580
  2. 29 Apr, 2022 1 commit
    • Jacob Boerema's avatar
      app: fix #8120 GIMP 2.10.30 crashed when allocate large memory · 8cd6d052
      Jacob Boerema authored
      GIMP could crash if the information regarding old path properties read
      from XCF was incorrect. It did not check if xcf_old_path succeeded and
      kept trying to load more paths even if the last one failed to load.
      
      Instead we now stop loading paths as soon as that function fails.
      In case we have a failure here we also try to skip to the next property
      based on the size of the path property, in hopes that the only problem
      was this property.
      
      (cherry picked from commit 4f99f1fc)
      8cd6d052
  3. 05 Apr, 2022 1 commit
    • Jacob Boerema's avatar
      app: fix #3928 GIMP cannot open .xcf · e4d8a91f
      Jacob Boerema authored
      GIMP stopped trying to read the XCF as soon as an invalid parasite was
      encountered. However, in this specific case only the parasite data is
      invalid, while the rest of the image is not corrupt.
      
      Instead of terminating when we see a corrupt parasite, we skip to the
      offset after the parasite. This may still be corrupt, but we can handle
      that correctly, see e.g. the XCF in bugzilla issue 685086, which was
      the reason of some of the previous changes.
      
      Additionally:
      - We add some logging to make it easier to handle future issues in this
        area.
      - We add tests for a NULL parasite name, and for reading a different
        amount of parasite data than we expected. In both cases we return
        NULL instead of a parasite.
      
      (cherry picked from commit 5b39bc96)
      e4d8a91f
  4. 22 Jan, 2021 1 commit
    • Jacob Boerema's avatar
      Issue #987 Corrupt 'gimp-metadata' parasite. Parsing XMP data failed. · 921ccef1
      Jacob Boerema authored
      XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
      making the XMP data invalid. There's not much we can do without a
      whole lot of processing and complicated code and even then no
      guarantee we would catch everything.
      
      Instead let's just try to improve the message to the user so they
      will be more likely to understand what's going on.
      
      (cherry picked from commit 6df6332f)
      921ccef1
  5. 22 Feb, 2020 1 commit
    • Ell's avatar
      app: suspend layer-group size updates while loading XCF · 878f2222
      Ell authored
      In xcf_load_image(), suspend size updates for layer groups before
      adding their sublayers, to avoid unnecessary intermediary size
      updates.  Resume size updates in reverse order, so that nested
      groups are updated before their ancestors, after all layers have
      been loaded.
      
      (cherry picked from commit 63df5602)
      878f2222
  6. 21 Feb, 2020 1 commit
    • Ell's avatar
      app: avoid use-after-free when loading an XCF with corrupted layers · 42b86556
      Ell authored
      When dropping a corrupted layer while loading an XCF, make sure to
      clear the corresponding XcfInfo fields that point to it, so that
      it's not erroneously used later, as we now continue loading the
      image even after corrupted layers are encountered.
      
      See, for example, issue #4643, for a corrputed XCF file affected by
      this.
      
      (cherry picked from commit d53e701d)
      42b86556
  7. 11 Jul, 2019 2 commits
    • Jehan's avatar
      app: salvage loaded group and text layer of dimension 0. · 465bedf6
      Jehan authored
      Whereas normal layers of dimension 0x0 are definitely broken, group and
      text layers depend on their contents, which will be able to resize the
      layer appropriately and fix whatever rendering. This commit allows to
      salvage such layers, hence make XCF loading even more resistant to
      certain form of file corruption.
      
      This commit (and the previous one) are not theoretical but the result of
      discovering some old corrupted file, with an empty group of size 0x0
      (saved by GIMP itself, because of some old bug). Rather than destroying
      these layer groups, this just allows us to reopen them without any kind
      of loss!
      
      (cherry picked from commit 06be0746)
      465bedf6
    • Jehan's avatar
      app: don't abandon immediately XCF loading at first layer load failure. · 8bc23461
      Jehan authored
      If the problem occurs at one of the first layer, we may end up loading
      nearly nothing even though there may be a whole lot of other data in
      good state. So instead keep track of the number of failed layer and
      channel loading to still display an error popup at the end, because we
      still need to alert the user something went wrong. Yet damages are
      limited.
      
      Also make sure that layer paths are fixed when some layers could not be
      loaded, hence stored paths end up wrong.
      
      (cherry picked from commit 2045fdd2)
      8bc23461
  8. 30 May, 2019 1 commit
  9. 03 Jan, 2019 1 commit
  10. 23 Oct, 2018 1 commit
  11. 16 Jul, 2018 2 commits
  12. 11 Jul, 2018 1 commit
  13. 06 Jul, 2018 2 commits
    • Ell's avatar
      Issue #1792 - Xcf file crashing gimp-console-2.10 ... · 2ac529cb
      Ell authored
      ... (valgrind reports Invalid read)
      
      Add gimp_babl_is_valid(), which takes a GimpImageBaseType and a
      GimpPrecision, and determines whether the image-type/precision
      combination is valid.  Use this function to validate that loaded
      XCFs use a valid type/precision combination, before trying to
      create the image.  Otherwise, we get a CRITICAL, and eventually a
      segfault, when the combination is invalid.
      
      Use the same function to validate the arguments of
      gimp_image_new().
      
      (cherry picked from commit a0a62656)
      2ac529cb
    • Ell's avatar
      app: avoid CRITICAL when loading XCF with empty gimp-image-metadata parasite · 6d7d0620
      Ell authored
      (cherry picked from commit d4ff57c7)
      6d7d0620
  14. 25 Apr, 2018 1 commit
  15. 06 Apr, 2018 1 commit
  16. 01 Apr, 2018 1 commit
  17. 13 Feb, 2018 2 commits
    • Ell's avatar
      app: small cleanup in xcf_load_channel_props() · fcde7bdf
      Ell authored
      Remove the impromptu boundary invalidation when converting a
      channel to a selection mask in xcf_load_channel_props(), as this
      happens implicitly when stealing the channel's buffer, since
      commit 38d4aa81.
      fcde7bdf
    • Ell's avatar
      Bug 793428 - Errors when loading an XCF with a saved selection mask · 38d4aa81
      Ell authored
      Since commit d0ae244f, which
      connects GimpChannel instances to their buffer's "changed" signal,
      the XCF loading code that steals a channel's buffer when converting
      it to a selection mask (which happens when loading an XCF with a
      saved selection mask) is unsafe, since fails to perform the
      necessary cleanup and setup of the buffer in the old and new
      channel objects, respectively.
      
      Perform the buffer transfer using the new
      gimp_drawable_steal_buffer(), which does the same thing in a safe
      manner.
      38d4aa81
  18. 19 Nov, 2017 1 commit
  19. 04 Oct, 2017 1 commit
  20. 01 Oct, 2017 3 commits
  21. 16 Sep, 2017 1 commit
  22. 19 Aug, 2017 1 commit
  23. 28 Jul, 2017 1 commit
    • Ell's avatar
      app: limit allowable tile data size in XCFs · 6b842930
      Ell authored
      When loading tiles from an XCF, reject tiles whose on-disk size is
      greater than 1.5 times the size of an uncompressed tile -- a limit
      that is already present for the last tile in the buffer.  This
      should allow for the possibility of negative compression, while
      restricting placing a realistic limit.
      
      Currently, no limit is placed on the on-disk tile data size.  When
      loading RLE- and zlib-compressed tiles, a buffer large enough to
      hold the entire on-disk tile data, up to 2GB, is allocated on the
      stack, and the data is read into it.  If the file is smaller than
      the reported tile data size, the area of the buffer past the end
      of the file is not touched.  This allows a malicious XCF to write
      up to 2GB of arbitrary data, at an arbitrary offset, up to 2GB,
      below the stack.
      
      Note that a similar issue had existed for earlier versions of GIMP
      (see commit d7a9e607), however,
      since prior to 2.9 the tile data buffer was allocated on the heap,
      the potential risk is far smaller.
      6b842930
  24. 21 May, 2017 1 commit
    • Ell's avatar
      app: future-proof XCF layer blend/composite props · e7d781ff
      Ell authored
      The layer blend space, composite space, and composite mode
      properties have a special AUTO value, which may map to different
      concrete values based on the layer mode.  Make sure we can change
      this mapping in the future, without affecting existing XCFs (saved
      after this commit), by encoding these properties as follows:
      
      When saving an XCF, if the property has a concrete (non-AUTO)
      value, which is always positive, encode it as is.  If the property
      is AUTO, which is always 0, encode it as the negative of the value
      it actually maps to at the time of saving (note that in some cases
      AUTO may map to AUTO, in which case it's encoded as 0).
      
      When loading an XCF, if the encoded property (stored in the file)
      is nonnegative, use it as is.  Otherwise, compare the negative of
      the encoded property to the value AUTO maps to at the time of
      loading.  If the values are equal, set the property to AUTO;
      otherwise, use the concrete value (i.e., the negative of the value
      stored in the XCF).
      
      Note that XCFs saved prior to this commit still load fine, it's
      simply that if we change the AUTO mapping in the future, all their
      AUTO properties will keep being loaded as AUTO, even if the
      resulting concrete values will have changed.
      e7d781ff
  25. 24 Mar, 2017 1 commit
  26. 23 Mar, 2017 3 commits
    • Michael Natterer's avatar
      app: change the "XCF compat" stuff to "XCF compression" · a0521a52
      Michael Natterer authored
      Both in the GimpImage API and in the GUI. The toggle in the save
      dialog now controls ZLIB compression directly. Changed the various
      info labels accordingly. Ditch the XCF parasite that saved the XCF
      compat mode.
      a0521a52
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · 01be1203
      Michael Natterer authored
      Change the xcf_read_foo() functions to take the XcfInfo* instead of
      a GInputStream*, and make them advance the info->cp offset by
      themselves. Makes xcf-load.c a lot more readable.
      01be1203
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · a0a5f714
      Michael Natterer authored
      Step one, without changing anything in the saved XCFs yet:
      
      Abstract reading and writing of file offsets away into their own
      xcf_read_offset() and xcf_write_offset() functions, which take
      "goffset" instead of "guint32". Also change xcf_seek_pos() to take a
      goffset argument.
      
      Change all file offset variables in xcf-load.c, xcf-write.c and struct
      XcfInfo to goffset, and add new member "bytes_per_offset" to XcfInfo,
      which is currently always 4.
      a0a5f714
  27. 26 Feb, 2017 1 commit
  28. 12 Feb, 2017 1 commit
  29. 01 Feb, 2017 1 commit
  30. 09 Jan, 2017 1 commit
  31. 08 Jan, 2017 1 commit