In Exiv2 before v0.27.2, there is an integer overflow vulnerability in the WebPImage::getHeaderOffset function in webpimage.cpp. It can lead to a buffer overflow vulnerability and a crash. References: https://github.com/Exiv2/exiv2/compare/v0.27.2-RC2...v0.27.2 https://github.com/Exiv2/exiv2/issues/960 https://github.com/Exiv2/exiv2/pull/962/commits/e925bc5addd881543fa503470c8a859e112cca62
First vulnerable commit (present only in master branch, not in v0.27 nor in v0.26): https://github.com/Exiv2/exiv2/commit/278a72570696f0c4793cc602691435f1ea292ae4 Upstream patch: https://github.com/Exiv2/exiv2/commit/a51980898bc30fa7831c7eda7f19b97caa27a130
The vulnerable commit introduces code like the following: ``` long WebPImage::getHeaderOffset(byte *data, size_t data_size, byte *header, size_t header_size) { long pos = -1; for (size_t i=0; i < data_size - header_size; i++) { [1] if (memcmp(header, &data[i], header_size) == 0) { [2] ``` When `data_size` is less than `header_size` there is a integer wraparound in [2] and the result is a big number. Thus when `data[i]` is access in [2], an out of bound reads happen. The issue cannot be reproduce in v0.27 branch and in v0.26 because function WebPImage::getHeaderOffset() in src/webpimage.cpp uses `long` types for variables `data_size`, `header_size` and `i`. In case the above condition applies, the result will be a negative number which, when compared with the signed value of `i`, will just prevent the for-loop to be executed.
Created exiv2 tracking bugs for this issue: Affects: fedora-all [bug 1775559]
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-14982