ryan/mozjpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

xform fuzz: Use src subsamp to calc dst buf size

Browse Source 
Referring to
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60379
there are some specially-crafted malformed JPEG images that, when
transformed to grayscale, will exceed the worst-case transformed
grayscale JPEG image size.  This is similar in nature to the issue fixed
by c8d52f1c4c, except that in this case,
the issue occurs regardless of the amount of metadata in the source
image.  Also, the tj3Transform() function, the
Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function,
and TJBench were behaving correctly in this case, because the TurboJPEG
API documentation specifies that the source image's subsampling type
should be used when computing the worst-case transformed JPEG image
size.  (However, only the Java API documentation specified that.  Oops.
The C API documentation now does as well.)  The documented usage
mitigates the issue, and only the transform fuzzer did not adhere to
that.  Thus, this was an issue with the fuzzer itself rather than an
issue with the library.
This commit is contained in:
DRC
2023-07-05 15:35:21 -04:00
parent 30c21e559d
commit 895287572d
3 changed files with 11 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
turbojpeg.h
View File

@@ -1862,13 +1862,14 @@ DLLEXPORT int tj3DecodeYUVPlanes8(tjhandle handle,
* -# set `dstBufs[i]` to NULL to tell TurboJPEG to allocate the buffer for
* you, or
* -# pre-allocate the buffer to a "worst case" size determined by calling
* #tj3JPEGBufSize() with the transformed or cropped width and height. Under
* normal circumstances, this should ensure that the buffer never has to be
* re-allocated. (Setting #TJPARAM_NOREALLOC guarantees that it won't be.)
* Note, however, that there are some rare cases (such as transforming images
* with a large amount of embedded EXIF or ICC profile data) in which the
* transformed JPEG image will be larger than the worst-case size, and
* #TJPARAM_NOREALLOC cannot be used in those cases.
* #tj3JPEGBufSize() with the transformed or cropped width and height and the
* level of subsampling used in the source image. Under normal circumstances,
* this should ensure that the buffer never has to be re-allocated. (Setting
* #TJPARAM_NOREALLOC guarantees that it won't be.) Note, however, that there
* are some rare cases (such as transforming images with a large amount of
* embedded EXIF or ICC profile data) in which the transformed JPEG image will
* be larger than the worst-case size, and #TJPARAM_NOREALLOC cannot be used in
* those cases.
* .
* If you choose option 1, then `dstSizes[i]` should be set to the size of your
* pre-allocated buffer. In any case, unless you have set #TJPARAM_NOREALLOC,