An integer overflow in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (SIGSEGV) via a crafted PNG image file, because PngImage::readMetadata mishandles a chunkLength - iccOffset subtraction.
cpe:2.3:a:exiv2:exiv2:*:*:*:*:*:*:*:*
4BFA28DF-4BFE-4CA7-A2F7-F471F91B856E
0.27.1
OR
cpe:2.3:o:fedoraproject:fedora:30:*:*:*:*:*:*:*
97A4B8DF-58DA-4AB6-A1F9-331B36409BA3
OR
This issue is closely related to #789, but the consequences of this bug are different. The calculation of  `chunkLength - iccOffset` at [pngimage.cpp:472](https://github.com/Exiv2/exiv2/blob/55dfdb9ab007d6e6d1d06240048690eaac23b305/src/pngimage.cpp#L472) can have a negative integer overflow which leads to an 8GB memory allocation in `zlibToDataBuf`. Also, the zlib decompression is run on uninitialized memory beyond the end of the buffer, so there is a potential info leak vulnerability here.

Here is the PoC, which I have tested on master ([55dfdb9](https://github.com/Exiv2/exiv2/commit/55dfdb9ab007d6e6d1d06240048690eaac23b305)): ![poc2](https://user-images.githubusercontent.com/4358136/56672813-fb6bcf00-66ae-11e9-9f14-6af4a90257c0.png). The simplest way to see the bug is to use `ulimit` to reduce the amount of available memory to less than 8GB:

```
$ ulimit -v 8000000
$ exiv2 poc2.png 
Uncaught exception: std::bad_alloc
```
Integer overflow, leading to very large allocation in PngImage::readMetadata()
This is a GitHub Issue
repo:exiv2
owner:Exiv2
Title : Integer overflow, leading to very large allocation in PngImage::readMetadata()
Issue date:

--- start body ---
This issue is closely related to #789, but the consequences of this bug are different. The calculation of  `chunkLength - iccOffset` at [pngimage.cpp:472](https://github.com/Exiv2/exiv2/blob/55dfdb9ab007d6e6d1d06240048690eaac23b305/src/pngimage.cpp#L472) can have a negative integer overflow which leads to an 8GB memory allocation in `zlibToDataBuf`. Also, the zlib decompression is run on uninitialized memory beyond the end of the buffer, so there is a potential info leak vulnerability here.

Here is the PoC, which I have tested on master ([55dfdb9](https://github.com/Exiv2/exiv2/commit/55dfdb9ab007d6e6d1d06240048690eaac23b305)): ![poc2](https://user-images.githubusercontent.com/4358136/56672813-fb6bcf00-66ae-11e9-9f14-6af4a90257c0.png). The simplest way to see the bug is to use `ulimit` to reduce the amount of available memory to less than 8GB:

```
$ ulimit -v 8000000
$ exiv2 poc2.png 
Uncaught exception: std::bad_alloc
```
--- end body ---

comments :
--- start comments ---

--- end comments ---