summaryrefslogtreecommitdiff
path: root/libtiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'fix_integer_overflow' into 'master'Even Rouault2019-08-148-107/+71
|\ | | | | | | | | Fix integer overflow in _TIFFCheckMalloc() and other implementation-defined behaviour (CVE-2019-14973) See merge request libtiff/libtiff!90
| * Fix integer overflow in _TIFFCheckMalloc() and other implementation-defined ↵Even Rouault2019-08-138-107/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour (CVE-2019-14973) _TIFFCheckMalloc()/_TIFFCheckRealloc() used a unsafe way to detect overflow in the multiplication of nmemb and elem_size (which are of type tmsize_t, thus signed), which was especially easily triggered on 32-bit builds (with recent enough compilers that assume that signed multiplication cannot overflow, since this is undefined behaviour by the C standard). The original issue which lead to this fix was trigged from tif_fax3.c There were also unsafe (implementation defied), and broken in practice on 64bit builds, ways of checking that a uint64 fits of a (signed) tmsize_t by doing (uint64)(tmsize_t)uint64_var != uint64_var comparisons. Those have no known at that time exploits, but are better to fix in a more bullet-proof way. Or similarly use of (int64)uint64_var <= 0.
* | TIFFClientOpen(): fix memory leak if one of the required callbacks is not ↵Even Rouault2019-08-121-0/+1
| | | | | | | | provided. Fixed Coverity GDAL CID 1404110
* | OJPEGReadBufferFill(): avoid very long processing time on corrupted files. ↵Even Rouault2019-08-121-2/+7
| | | | | | | | Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16400. master only
* | OJPEG: fix integer division by zero on corrupted subsampling factors. Fixes ↵Even Rouault2019-08-101-0/+6
|/ | | | https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15824. Credit to OSS Fuzz
* Reading of Tiff tags with ID = 0 (like GPSVERSIONID) corrected.Su Laus2019-08-042-184/+183
| | | | | | | | | | | | | | | | | | | | | IGNORE placeholder in tif_dirread.c is now replaced by a field dir_ignore in the TIFFDirEntry structure Currently, in tif_dirread.c a special IGNORE value for the tif tags is defined in order to flag status preventing already processed tags from further processing. This irrational behaviour prevents reading of custom tags with id code 0 - like tag GPSVERSIONID from EXIF 2.31 definition. An additional field 'tdir_ignore' is now added to the TIFFDirEntry structure and code is changed to allow tags with id code 0 to be read correctly. This change was already proposed as pending improvement in tif_dirread.c around line 32. Reference is also made to: - Discussion in https://gitlab.com/libtiff/libtiff/merge_requests/39 - http://bugzilla.maptools.org/show_bug.cgi?id=2540 Comments and indention adapted. Preparation to rebase onto master
* TIFFWriteCheck(): call TIFFForceStrileArrayWriting() when needed (should ↵Even Rouault2019-07-091-0/+14
| | | | have gone with eaeca6274ae71cdfaeb9f673b6fb0f3cfc0e6ce5) (master only)
* OJPEG: avoid use of unintialized memory on corrupted filesEven Rouault2019-07-051-0/+26
| | | | | Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=925269 Patch from Lei Zhang with little adaptations.
* Return infinite distance when denominator is zero.Dirk Lemstra2019-06-291-1/+1
|
* Merge branch 'defer_strile_writing' into 'master'Even Rouault2019-05-296-57/+252
|\ | | | | | | | | Add TIFFDeferStrileArrayWriting() and TIFFForceStrileArrayWriting() See merge request libtiff/libtiff!82
| * Add TIFFDeferStrileArrayWriting() and TIFFForceStrileArrayWriting()Even Rouault2019-05-256-57/+252
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those advanced writing functions must be used in a particular sequence to make their intended effect. Their aim is to control when/where the [Strip/Tile][Offsets/ByteCounts] arrays are written into the file. The purpose of this is to generate 'cloud-optimized geotiff' files where the first KB of the file only contain the IFD entries without the potentially large strile arrays. Those are written afterwards. The typical sequence of calls is: TIFFOpen() [ TIFFCreateDirectory(tif) ] Set fields with calls to TIFFSetField(tif, ...) TIFFDeferStrileArrayWriting(tif) TIFFWriteCheck(tif, ...) TIFFWriteDirectory(tif) ... potentially create other directories and come back to the above directory TIFFForceStrileArrayWriting(tif): emit the arrays at the end of file See test/defer_strile_writing.c for a practical example.
* | Merge branch 'TIFFReadFromUserBuffer' into 'master'Even Rouault2019-05-293-0/+91
|\ \ | | | | | | | | | | | | Add TIFFReadFromUserBuffer() See merge request libtiff/libtiff!81
| * | Add TIFFReadFromUserBuffer()Even Rouault2019-05-233-0/+91
| | | | | | | | | | | | | | | | | | | | | This function replaces the use of TIFFReadEncodedStrip()/TIFFReadEncodedTile() when the user can provide the buffer for the input data, for example when he wants to avoid libtiff to read the strile offset/count values from the [Strip|Tile][Offsets/ByteCounts] array.
* | | Fix vulnerability in 'D' (DeferStrileLoad) mode (master only) (fixes ↵Even Rouault2019-05-261-1/+3
| | | | | | | | | | | | https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14908)
* | | Replace 'stripped' by 'striped' in error messagesEven Rouault2019-05-254-4/+4
| |/ |/|
* | Fix vulnerability introduced by defer strile loading (master only)Even Rouault2019-05-242-3/+6
| | | | | | | | | | | | | | | | Found on GDAL with https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14894 Disabling the TIFF_DEFERSTRILELOAD bit in ChopupStripArray() was a bad idea since when using TIFFReadDirectory() to reload the directory again would lead to a different value of td_rowsperstrip, which could confuse readers if they relied on the value found initially.
* | Fix typo in error message (master only)Even Rouault2019-05-241-1/+1
|/
* libtiff.def: add missing new symbolsEven Rouault2019-05-221-0/+4
|
* _TIFFRewriteField(): fix for bigtiff case (master only)Even Rouault2019-05-221-1/+1
| | | | | 116cf67f4c59196605abdb244657c3070c4310af made StripByteCount/TileByteCount to always be rewritten as TIFF_LONG8.
* Merge branch 'ondemand_strile_offbytecount_loading' into 'master'Even Rouault2019-05-2113-258/+575
|\ | | | | | | | | Make defer strile offset/bytecount loading available at runtime See merge request libtiff/libtiff!79
| * Make defer strile offset/bytecount loading available at runtimeEven Rouault2019-05-1013-258/+575
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and add per-strile offset/bytecount loading capabilities. Part of this commit makes the behaviour that was previously met when libtiff was compiled with -DDEFER_STRILE_LOAD available for default builds when specifying the new 'D' (Deferred) TIFFOpen() flag. In that mode, the [Tile/Strip][ByteCounts/Offsets] arrays are only loaded when first accessed. This can speed-up the opening of files stored on the network when just metadata retrieval is needed. This mode has been used for years by the GDAL library when compiled with its embeded libtiff copy. To avoid potential out-of-tree code (typically codecs) that would use the td_stripbytecount and td_stripoffset array inconditionnaly assuming they have been loaded, those have been suffixed with _p (for protected). The use of the new functions mentionned below is then recommended. Another addition of this commit is the capability of loading only the values of the offset/bytecount of the strile of interest instead of the whole array. This is enabled with the new 'O' (Ondemand) flag of TIFFOpen() (which implies 'D'). That behaviour has also been used by GDAL, which hacked into the td_stripoffset/td_stripbytecount arrays directly. The new code added in the _TIFFFetchStrileValue() and _TIFFPartialReadStripArray() internal functions is mostly a port of what was in GDAL GTiff driver previously. Related to that, the public TIFFGetStrileOffset[WithErr]() and TIFFGetStrileByteCount[WithErr]() functions have been added to API. They are of particular interest when using sparse files (with offset == bytecount == 0) and you want to detect if a strile is present or not without decompressing the data, or updating an existing sparse file. They will also be used to enable a future enhancement where client code can entirely skip bytecount loading in some situtations A new test/defer_strile_loading.c test has been added to test the above capabilities.
* | Creation: use SHORT type when possible for StripByteCounts/TileByteCountsEven Rouault2019-05-101-29/+99
| | | | | | | | This follows the same logic as previous commit.
* | BigTIFF creation: write TileByteCounts/StripByteCounts tag with LONG when ↵Even Rouault2019-05-091-5/+64
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | possible In most situations of BigTIFF file, the tile/strip sizes are of reasonable size, that is they fit on a 4-byte LONG. So in that case, use LONG instead of LONG8 to save some space. For uncompressed file, it is easy to detect such situations by checking at the TIFFTileSize64()/TIFFStripSize64() return. For compressed file, we must take into account the fact that compression may sometimes result in larger compressed data. So we allow this optimization only for a few select compression times, and take a huge security margin (10x factor). We also only apply this optimization on multi-strip files, so as to allow easy on-the-fly growing of single-strip files whose strip size could grow above the 4GB threshold. This change is compatible with the BigTIFF specification. According to https://www.awaresystems.be/imaging/tiff/bigtiff.html: "The StripOffsets, StripByteCounts, TileOffsets, and TileByteCounts tags are allowed to have the datatype TIFF_LONG8 in BigTIFF. Old datatypes TIFF_LONG, and TIFF_SHORT where allowed in the TIFF 6.0 specification, are still valid in BigTIFF, too. " On a practical point of view, this is also compatible on reading/writing of older libtiff 4.X versions. The only glitch I found, which is rather minor, is when using such a BigTIFF file with TileByteCounts/StripByteCounts written with TIFF_LONG, and updating it with an older libtiff 4.X version with a change in the [Tile/Strip][ByteCounts/Offsets] array. In that case the _TIFFRewriteField() function will rewrite the directory and array with TIFF_LONG8, instead of updating the existing array (this is an issue fixed by this commit). The file will still be valid however, hence the minor severity of this.
* Merge branch 'bug_2829' into 'master'Even Rouault2019-05-081-1/+1
|\ | | | | | | | | WIN32: use tif_win32.c when building with CMake See merge request libtiff/libtiff!75
| * WIN32: use tif_win32.c when building with CMakeThomas Bernard2019-04-251-1/+1
| | | | | | | | | | | | | | | | | | see http://bugzilla.maptools.org/show_bug.cgi?id=2829 the top CMakeLists.txt defines win32_io and USE_WIN32_FILEIO WIN32_IO is defined nowhere in CMake (only in automake things)
* | Reading error for FileSource and SceneType tags corrected.Su Laus2019-05-061-0/+1
|/ | | | | | EXIF tags FILESOURCE and SCENETYPE are defined as TIFF_UNDEFINED and field_readcount==1! There is a bug in TIFFReadDirEntryByte() preventing to read correctly type TIFF_UNDEFINED fields with field_readcount==1 Upgrade of TIFFReadDirEntryByte() with added TIFF_UNDEFINED switch-entry allows libtiff to read those tags correctly.
* TIFFWriteEncodedStrip/TIFFWriteEncodedTile: fix rewriting of LZW-compressed dataEven Rouault2019-04-111-37/+35
| | | | | | | | Fixes https://github.com/OSGeo/gdal/issues/1439 When rewriting a LZW tile/strip whose existing size is very close to a multiple of 1024 bytes (and larger than 8192 bytes) with compressed data that is larger, the new data was not placed at the end of the file, causing corruption.
* Merge branch 'bug2848' into 'master'Even Rouault2019-04-081-3/+3
|\ | | | | | | | | tif_luv.c: LogLuvSetupEncode() error must return 0 See merge request libtiff/libtiff!72
| * tif_luv.c: LogLuvSetupEncode() error must return 0Thomas Bernard2019-03-221-3/+3
| | | | | | | | | | | | | | see http://bugzilla.maptools.org/show_bug.cgi?id=2848 if wrongly returning 1, the processing of incorrect file continues, which causes problems.
* | tif_read.c: potentially fix false positive from Coverity Scan. CID 1400288Even Rouault2019-03-231-1/+2
| |
* | tif_read.c: potentially fix false positive from Coverity Scan. CID 1400271Even Rouault2019-03-231-0/+5
| |
* | tif_zip.c: remove dead code. CID 1400360Even Rouault2019-03-231-2/+0
| |
* | tif_webp.c: remove false positive warning about dereference before null ↵Even Rouault2019-03-231-6/+4
| | | | | | | | check. CID 1400255
* | tif_pixarlog.c: remove dead code. CID 1400342Even Rouault2019-03-231-2/+0
| |
* | tif_pixarlog.c: avoid false positive Coverity Scan warnings about overflow. ↵Even Rouault2019-03-231-0/+2
| | | | | | | | CID 1400300 and 1400367
* | tif_lzw.c: silence CoverityScan false positive. CID 1400355Even Rouault2019-03-231-0/+2
| |
* | tif_luv.c: silence CoverityScan false positive. CID 1400231, 1400251, ↵Even Rouault2019-03-231-3/+8
| | | | | | | | 1400254, 1400272, 1400318, 1400356
* | TryChopUpUncompressedBigTiff(): avoid potential division by zero. master ↵Even Rouault2019-03-231-1/+1
|/ | | | only. GDAL Coverity CID 1400263
* Merge branch 'large_strile_improvements' into 'master'Even Rouault2019-02-222-76/+188
|\ | | | | | | | | Large strile support improvements See merge request libtiff/libtiff!63
| * tif_zip.c: allow reading and writing strips/tiles with more than 4 GB of ↵Even Rouault2019-02-191-35/+19
| | | | | | | | compressed or uncompressed data
| * tif_dirread.c: when strip chopping is enabled, extend this mechanism to ↵Even Rouault2019-02-191-41/+169
| | | | | | | | multi-strip uncompressed files with strips larger than 2GB to expose them as strips of ~500 MB
* | move _TIFFClampDoubleToFloat() to tif_aux.cThomas Bernard2019-02-124-26/+18
|/ | | | | | the same function was declared in tif_dir.c and tif_dirwrite.c see http://bugzilla.maptools.org/show_bug.cgi?id=2842
* Fix warning (use of uninitialized value) added per ↵Even Rouault2019-02-021-12/+16
| | | | d0a842c5dbad2609aed43c701a12ed12461d3405 (fixes https://gitlab.com/libtiff/libtiff/merge_requests/54#note_137742985)
* Merge branch 'bug2833' into 'master'Even Rouault2019-02-011-2/+4
|\ | | | | | | | | TIFFWriteDirectoryTagTransferfunction() : fix NULL dereferencing See merge request libtiff/libtiff!54
| * TIFFWriteDirectoryTagTransferfunction() : fix NULL dereferencingThomas Bernard2019-01-291-2/+4
| | | | | | | | | | | | http://bugzilla.maptools.org/show_bug.cgi?id=2833 we must check the pointer is not NULL before memcmp() the memory
* | Merge branch 'master' into 'master'Even Rouault2019-02-011-0/+22
|\ \ | |/ |/| | | | | tif_dir: unset transferfunction field if necessary (CVE-2018-19210) See merge request libtiff/libtiff!47
| * tif_dir: unset transferfunction field if necessaryHugo Lefeuvre2018-12-141-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The number of entries in the transfer table is determined as following: (td->td_samplesperpixel - td->td_extrasamples) > 1 ? 3 : 1 This means that whenever td->td_samplesperpixel or td->td_extrasamples are modified we also need to make sure that the number of required entries in the transfer table didn't change. If it changed and the number of entries is higher than before we should invalidate the transfer table field and free previously allocated values. In the other case there's nothing to do, additional tf entries won't harm and properly written code will just ignore them since spp - es < 1. For instance this situation might happen when reading an OJPEG compressed image with missing SamplesPerPixel tag. In this case the SamplesPerPixel field might be updated after setting the transfer table. see http://bugzilla.maptools.org/show_bug.cgi?id=2500 This commit addresses CVE-2018-19210.
* | Do not attempt to re-sync zip stream after reported data error from inflate().Bob Friesenhahn2018-12-082-4/+4
| |
* | fixed mem leak in webp compressionNorman Barker2018-11-281-4/+10
|/
* fixed lossless webp compression configNorman Barker2018-11-201-9/+16
|
View Lorry Controller Status