SIGFPE on specially crafted jpeg - b6029d31 #153
Comments
|
Good find. |
dcommander
added a commit
to libjpeg-turbo/libjpeg-turbo
that referenced
this issue
Aug 13, 2015
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
|
The root of this problem is that rdbmp.c uses the ambiguous INT32 type. Windows bitmap headers are defined with very specific types: https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx (DWORD = unsigned int, LONG = int, WORD = unsigned short) libjpeg-turbo/libjpeg-turbo@3a6cadf fixes this by using the appropriate types that match the Windows bitmap header spec. |
7er
pushed a commit
to imazen/libjpeg-turbo
that referenced
this issue
Sep 17, 2015
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
dcommander
added a commit
to libjpeg-turbo/libjpeg-turbo
that referenced
this issue
Oct 3, 2015
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
lilith
pushed a commit
to imazen/libjpegturbo
that referenced
this issue
Oct 12, 2015
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes libjpeg-turbo#9 and also provides a better solution for mozilla/mozjpeg#153.
kornelski
added a commit
to ImageOptim/mozjpeg-cocoa
that referenced
this issue
Apr 27, 2016
* origin/master: (108 commits) Bump version number to 3.1. jpegyuv: fix memory leak when path is invalid jpegyuv: fix memory leak when @image_buffer allocation fails yuvjpeg: fix memory leak when @image_buffer allocation fails jpegtran: Do not leak the input and output buffers Fix previous commit Scan optimization: return error when unable to copy data buffer cjpeg option for baseline quant tables Fix mozilla#153 rdpng: convert 16-bit input to 8-bit Larger number of DC trellis candidates Fix overflow issue mozilla#157 Const on getters Const on simple getters and copy source Expanded .gitignore Add pkg-config requirement Re-order links. Declare inbuffer const Oops. Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package. Get rid of changelog file that we don't update. ...
xinyu391
pushed a commit
to xinyu391/mozjpeg
that referenced
this issue
Sep 25, 2018
Fulfills part of the feature request in mozilla#153. Also paves the way for SIMD-accelerated progressive Huffman coding (refer to mozilla#46.)
xinyu391
pushed a commit
to xinyu391/mozjpeg
that referenced
this issue
Sep 25, 2018
Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes mozilla#153
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Mozilla team,
I am running from the master branch here.
The following file causes a SIGFPE in lt-cjpeg on my platform:
https://www.dropbox.com/s/a03ddlno6v6ubzz/b6029d31?dl=0
To reproduce:
cjpeg -outfile /dev/null b6029d31
Output:
Aborted
GDB output, (not very useful at the moment, I am going to work on that):
System Details:
AMD64
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
Found with the fuzzer American Fuzzy Lop ( http://lcamtuf.coredump.cx/afl/ )
The text was updated successfully, but these errors were encountered: