Fixes a crash and an infinite loop in stb_image that could occur with specially constructed PGM and HDR files #1223
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 7, 2021
musicinmybrain
added a commit
to musicinmybrain/zxing-cpp
that referenced
this pull request
Dec 8, 2021
Fixes a crash and an infinite loop in stb_image that could occur with specially constructed PGM and HDR files nothings/stb#1223 This is a candidate fix for: https://nvd.nist.gov/vuln/detail/CVE-2021-42715 In stb_image's HDR reader, loading a specially constructed invalid HDR file can result in an infinite loop within the RLE decoder nothings/stb#1224 Additionally, this is a candidate fix for: https://nvd.nist.gov/vuln/detail/CVE-2021-42716 stbi__pnm_load heap-buffer-overflow bug nothings/stb#1166 In stb_image's PNM reader, loading a specially constructed valid 16-bit PGM file with 4 channels can cause a crash due to an out-of-bounds read nothings/stb#1225
|
Following up on this - is there anything I can change to help merge this in? Thanks! |
|
stb repository is just slow for me to update |
|
Quick note from the survey of the first 10 ossfuzz issues I did: I think this pull request might resolve ossfuzz issues https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37628&q=proj%3Dstb&can=2 (this seems to be the infinite HDR reader error) and https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38394&q=proj%3Dstb&can=2 (I think this is due to the PGM issue). I'm unable to reproduce ossfuzz's crashes with these fixes on Windows with Address Sanitizer enabled. |
slouken
pushed a commit
to libsdl-org/SDL_image
that referenced
this pull request
May 28, 2022
Mainstream pull requests: nothings/stb#1230 nothings/stb#1223 nothings/stb#1297 Related mainstream issue tickets: nothings/stb#1224 nothings/stb#1225 nothings/stb#1289 nothings/stb#1291 nothings/stb#1292 nothings/stb#1293
…d HDR and PGM files. Signed-off-by: Neil Bickford <[email protected]>
NBickford-NV
force-pushed
the
neilbickford/image_hdr_pgm_fixes
branch
from
8075c34
to
2a02ff7
Compare
|
Merged into dev branch, will be in the next release. |
|
Thanks so much ryg! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes two availability issues in stb_image that could occur with specially
constructed HDR and PGM files. Please see issues #1224 and #1225 for full descriptions.
HDR: In certain conditions, the RLE decoder can get stuck in the decoding loop
at the end of a stream:
stbi__get8()always returns 0 when at the end of astream, which is interpreted as a count and results in an infinite loop.
I believe the solution is to treat a run of 0 as invalid, following the
RGBE_ReadPixels_RLE()function in Bruce Walter'shttps://www.graphics.cornell.edu/~bjw/rgbe/rgbe.c.
PGM: Loading large monochrome 16-bit PGM files would cause an access violation
due to reading out of bounds when comverting from 16-bit to 8-bit. In addition,
when loading 16-bit PGM files,
stbi__pnm_load()would callstbi__convert_format()instead ofstbi__convert_format16()to convert frommonochrome to the required number of channels, so the buffer would be
interpreted as the wrong type. This pull request also adds an error nessage for
when the
stbi__getn()call fails.Thanks!