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

ChangeLog.md: List CVE ID fixed by c76f4a08

Browse Source 
Referring to #527, the security community did not assign this CVE ID
until more than 8 months after the fix for the issue was released.  By
the time they assigned the ID, libjpeg-turbo already had two production
releases containing the fix.  This calls into question the usefulness of
assigning a CVE ID to the issue, particularly given that the buffer
overrun in question was fully contained in the stack, not detectable
with valgrind, and confined to lossless transformation (it did not
affect JPEG compression or decompression.)

https://vuldb.com/?id.176175
says that "the exploitability is told to be easy" but provides no
clarification, and given that the author of that page does not seem to
be aware that a fix for the issue has been available since early
December of 2019, it calls into question the accuracy of everything else
on the page.

It would really be nice if the security community approached me about
these things before wasting my time, but I guess it's my lot in life to
modify a change log entry from 2019 to include a CVE ID from 2020.

So it goes...
This commit is contained in:
DRC
2021-06-18 09:46:03 -05:00
parent 5135c2e25d
commit 1a1fb615db
1 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
ChangeLog.md
View File

@@ -293,15 +293,15 @@ JPEG images. This was known to cause a buffer overflow when attempting to
decompress some such images using `tjDecompressToYUV2()` or decompress some such images using `tjDecompressToYUV2()` or
`tjDecompressToYUVPlanes()`. `tjDecompressToYUVPlanes()`.
5. Fixed an issue, detected by ASan, whereby attempting to losslessly transform 5. Fixed an issue (CVE-2020-17541), detected by ASan, whereby attempting to
a specially-crafted malformed JPEG image containing an extremely-high-frequency losslessly transform a specially-crafted malformed JPEG image containing an
coefficient block (junk image data that could never be generated by a extremely-high-frequency coefficient block (junk image data that could never be
legitimate JPEG compressor) could cause the Huffman encoder's local buffer to generated by a legitimate JPEG compressor) could cause the Huffman encoder's
be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that the buffer local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that
overrun was fully contained within the stack and did not cause a segfault or the buffer overrun was fully contained within the stack and did not cause a
other user-visible errant behavior, and given that the lossless transformer segfault or other user-visible errant behavior, and given that the lossless
(unlike the decompressor) is not generally exposed to arbitrary data exploits, transformer (unlike the decompressor) is not generally exposed to arbitrary
this issue did not likely pose a security risk. data exploits, this issue did not likely pose a security risk.
6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a 6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a
separate read-only data section rather than in the text section, to support separate read-only data section rather than in the text section, to support