-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
heap-buffer-overflow in stbi__jpeg_load #1178
Comments
The component resamplers are not written to support this and I've never seen it happen in a real (non-crafted) JPEG file so I'm fine rejecting this as outright corrupt. Fixes issue #1178.
|
Thanks for the repro, fix for this issue is pushed to the dev branch and will be in the next release. The underlying problem here is that the resampling code assumes that the plane resampling factors are integer factors (i.e. planes need to be upscaled by 2x, 3x or similar) and in this case the ratio works out to 1.5x; the calculation in All real JPEGs I've ever encountered have integer subsampling factors, so I just changed |
The component resamplers are not written to support this and I've never seen it happen in a real (non-crafted) JPEG file so I'm fine rejecting this as outright corrupt. Fixes issue #1178.
|
Fix was merged into master on Aug 13, 2021 and this bug wasn't closed, but it's fixed. |
poc.zip
I find heap-buffer-overflow in stbi__jpeg_load with lastest version: 2.27
clang test.cpp -fsanitize=address -o test./test poc.jpgASAN log:
Analyze this bug:
In stbi_imgae.h version less than 2.27, the function load_jpeg_image will calculate the w_lores, and image_x, and in function stbi__process_frame_header, the will clac z->img_comp[i].w2, In some special h and v values, w_lores is
not equal to z->img_comp[k].w2, and load_jpeg_image will call r->resample to copy w_lores size , So it leads to oob read
The text was updated successfully, but these errors were encountered: