A WebPImage::decodeChunks integer overflow in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (large heap allocation followed by a very long running loop) via a crafted WEBP image file.
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
There is a bug at [webpimage.cpp:515](https://github.com/Exiv2/exiv2/blob/55dfdb9ab007d6e6d1d06240048690eaac23b305/src/webpimage.cpp#L515). If `filesize < io_->tell()` then the subtraction overflows and the bounds check on `size` is ineffective.

There is an additional problem in this function, which is that the error conditions are not checked after the calls to `io_->read`. Calls to `io_->read` should always be followed by calls to `io_->error()` and `io_->eof()`, to make sure that the buffer was read successfully. This means that the code does not notice that the file size is much smaller than the value of `size` would suggest. This has enabled me to write a PoC which causes exiv2 to run for almost a minute, scanning 4GB of uninitialized memory.

Here is the PoC, which I have tested on master ([55dfdb9](https://github.com/Exiv2/exiv2/commit/55dfdb9ab007d6e6d1d06240048690eaac23b305)): 
![poc1](https://user-images.githubusercontent.com/4358136/56674700-57842280-66b2-11e9-901a-bedeb60ba307.jpg). You can run the PoC like this to see the long-running behavior:

```
$ time exiv2 poc1.jpg  
File name       : poc1.jpg
File size       : 28 Bytes
MIME type       : image/webp
Image size      : 0 x 0
poc1.jpg: No Exif data found in the file

real    0m52.738s
user    0m50.621s
sys     0m2.108s
```

Or if you use `ulimit` to lower the maximum allocation size to less than 4GB then exiv2 will crash:

```
$ ulimit -v 4000000
$ exiv2 poc1.jpg
Uncaught exception: std::bad_alloc
```
Integer overflow, leading to very large allocation in WebPImage::decodeChunks()
This is a GitHub Issue
repo:exiv2
owner:Exiv2
Title : Integer overflow, leading to very large allocation in WebPImage::decodeChunks()
Issue date:

--- start body ---
There is a bug at [webpimage.cpp:515](https://github.com/Exiv2/exiv2/blob/55dfdb9ab007d6e6d1d06240048690eaac23b305/src/webpimage.cpp#L515). If `filesize < io_->tell()` then the subtraction overflows and the bounds check on `size` is ineffective.

There is an additional problem in this function, which is that the error conditions are not checked after the calls to `io_->read`. Calls to `io_->read` should always be followed by calls to `io_->error()` and `io_->eof()`, to make sure that the buffer was read successfully. This means that the code does not notice that the file size is much smaller than the value of `size` would suggest. This has enabled me to write a PoC which causes exiv2 to run for almost a minute, scanning 4GB of uninitialized memory.

Here is the PoC, which I have tested on master ([55dfdb9](https://github.com/Exiv2/exiv2/commit/55dfdb9ab007d6e6d1d06240048690eaac23b305)): 
![poc1](https://user-images.githubusercontent.com/4358136/56674700-57842280-66b2-11e9-901a-bedeb60ba307.jpg). You can run the PoC like this to see the long-running behavior:

```
$ time exiv2 poc1.jpg  
File name       : poc1.jpg
File size       : 28 Bytes
MIME type       : image/webp
Image size      : 0 x 0
poc1.jpg: No Exif data found in the file

real    0m52.738s
user    0m50.621s
sys     0m2.108s
```

Or if you use `ulimit` to lower the maximum allocation size to less than 4GB then exiv2 will crash:

```
$ ulimit -v 4000000
$ exiv2 poc1.jpg
Uncaught exception: std::bad_alloc
```
--- end body ---

comments :
--- start comments ---

--- end comments ---