You've already forked libjpeg-turbo
mirror of
https://github.com/libjpeg-turbo/libjpeg-turbo.git
synced 2026-10-23 11:48:53 +03:00
f59b3d49c6
The destination manager always tracked the destination buffer size from previous compression or transform function calls, even if TJPARAM_NOREALLOC was 1 during those previous calls. That was incorrect behavior per the documentation, because the destination buffer is only supposed to be API-managed if TJPARAM_NOREALLOC is 0. Under rare circumstances, the incorrect behavior exposed an issue with our own compress fuzzer (https://issues.oss-fuzz.com/issues/511253454) whereby, on the fourth test, malloc() reused the memory block from the third test (the only test with TJPARAM_NOREALLOC=1), causing the destination manager to think that the destination buffer was allocated to the worst-case size instead of 100 bytes. This led to a fully-contained buffer overrun. In practice, the issue was thwarted by ASan and valgrind, so OSS-Fuzz caught it only when testing with UBSan. In my lab, the issue occurred only with an Ubuntu 26.04/AArch64 virtual machine and only if the libjpeg-turbo SIMD extensions were disabled. Note that bufReuseTest() in tjunittest previously worked around the aforementioned incorrect behavior. It now tests for it. This commit also modifies the compress fuzzer so that it doesn't reallocate the destination buffer while it is API-managed. Additional issues stemming from that were extremely unlikely, however, since the destination buffer was reallocated to 100 bytes every time. (If the buffer had automatically been reallocated during a previous test, then it is extremely unlikely that malloc() would have reused the memory block of the reallocated buffer.)