You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=637) [details] Invalid LogL TIFF Calling TIFFReadRGBAImage() on the attached "broken_2.tif" will result in an out of bounds write at tif_luv.c:208. The assert at tif_luv.c:205 is triggered, but this is ignored by many clients. The cause of this issue is that the attached image is of compression type "LogL" and has an invalid number of samples per pixel. My understanding is that LogL should only ever contain a single sample per pixel and thus it would make sense to detect this condition and return an error in TIFFRGBAImageOK(). Here is a diff of what I believe the fix should be: $ diff -u libtiff/libtiff/tif_getimage_orig.c libtiff/libtiff/tif_getimage.c --- libtiff/libtiff/tif_getimage_orig.c 2015-09-10 16:52:48.125129413 -0700 +++ libtiff/libtiff/tif_getimage.c 2015-09-10 16:51:20.627963797 -0700 @@ -169,6 +169,13 @@ "Compression", COMPRESSION_SGILOG); return (0); } + if( td->td_samplesperpixel != 1 ) + { + sprintf(emsg, + "Sorry, can not handle image with %s=%d", + "Samples/pixel", td->td_samplesperpixel); + return 0; + } break; case PHOTOMETRIC_LOGLUV: if (td->td_compression != COMPRESSION_SGILOG &&
(From update of attachment 637 [details]) Browser won't let me on alot of sites. Connections are not private. Been working with it for a while. Don't seem to get the right fix though.
Fixed with tif_luv.c revision: 1.41 2015-12-27 Even Rouault <even.rouault at spatialys.com> * libtiff/tif_luv.c: fix potential out-of-bound writes in decode functions in non debug builds by replacing assert()s by regular if checks (bugzilla #2522). Fix potential out-of-bound reads in case of short input data.
