To make the plugins fail to allocate if the image size is greater than QImageReader::allocationLimit() it is necessary to allocate the image with QImageIOHandler::allocateImage().
Note that not all plugins have been changed and some others are not tested in the CI (maybe due to missing libraries).
PS: the following message is printed by QImageIOHandler::allocateImage() if the size is exceeded: "qt.gui.imageio: QImageIOHandler: Rejecting image as it exceeds the current allocation limit of XXX megabytes"
- Fix parasite "gimp-comment" not set due to null QImage
- Support to parasite "icc-profile" using Qt 5.14+ API
- Added parasite "gimp-image-metadata" as QImage metadata "XML:org.gimp.xml"
- Added a XCF with XML metadata and icc prifile embedded in autotest folder (generated by GIMP 2.10.30)
- Tested with Qt 5.15.2 and Qt 6.2.3 under Windows and Qt 6.2.3 under macOS
It's not a huge problem since QIODevice::seek() is a noop on negative values but it's
just better to bail out as soon as possible when we realize the file is
broken
According to relicensecheck Brad is OK with changing LGPLv2 to LGPLv2+,
which is required to be compatible with the LGPL-2.1-or-later licensed
source files.
We added our own implementation of rand_r to make sure we use the same
as Gimp, and to make Windows work. But we need to actually use it
everywhere.
Discussion in Differential:
Differential Revision: https://phabricator.kde.org/D25267
We now support up to and including version 11 of the XCF format, earlier
it only supported version 1 (from 1997, according to the XCF spec).
Biggest difference seems to be that they changed to 64bit for offsets
from version 11 and upwards, otherwise it's mostly just newer enum
values and theoretically major stuff that we don't really need to care
about to get a thumbnail (e. g. linear vs. perceptual RGB).
We still don't support all features, but now it handles that more
gracefully and should at least create thumbnails that are usable. It
should also be easier to update in the future if/when there comes new
versions.
Also added a test file created with the latest version of Gimp
(2.10.18).
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D25937
Summary:
The fact that we don't know the property is most of the times not fatal,
so what we have to do is just "skip" the property and hope for the best
BUGS: 411327
Reviewers: cfeck, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24114
Summary:
QDataStream reads 64 bits when reading into a float unless you tell it to use SinglePrecision,
since floats in xcf are 32 bit, do that
Reviewers: cfeck, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24113
Summary:
I had a look at some image loading code in kimageformats and found memory
corruption bugs (there might be more):
- oobwrite4b.xcf: OOB write in kimg_xcf:
By overflowing the "size = 3 * ncolors + 4;" calculation, it's possible to make
size == 3 or size == 0, which then allows 1 or 4 bytes to be overwritten:
https://cgit.kde.org/kimageformats.git/tree/src/imageformats/xcf.cpp?id=3f2552f21b1cdef063c2a93cc95d42a8cf907fcf#n484
The values aren't arbitrary, so AFAICT DoS only.
Fix is to move the sanity check for size below the assignment.
- oobread.tga: OOB read in kimg_tga:
By overflowing the "size = tga.width * tga.height * pixel_size" calculation,
it's possible to cause OOB reads later on as the image data array is too small:
https://cgit.kde.org/kimageformats.git/tree/src/imageformats/tga.cpp?id=3f2552f21b1cdef063c2a93cc95d42a8cf907fcf#n192
Fix is to use a 64bit integer instead.
- oobwrite4b.tga/oobwrite507.tga: OOB write in kimg_tga
If RLE is enabled, any size checks are skipped, so it's possible to write
either 128 repetitions of an arbitrary four byte value (oobwrite4b.tga)
or or 507 arbitrary bytes (oobwrite507.tga) out of bounds.
https://cgit.kde.org/kimageformats.git/tree/src/imageformats/tga.cpp?id=3f2552f21b1cdef063c2a93cc95d42a8cf907fcf#n209
Fix is to check for "num" being negative before reading into the buffer.
Also, bail out early if there is no more data available (reading a 65kx65k px image from 14B data takes ages otherwise)
Test Plan:
Stopped crashing and valgrind don't complain anymore.
TGA preview still works for valid files.
Reviewers: aacid
Reviewed By: aacid
Subscribers: lbeltrame, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D18574
The GIMP image loader had a limit to 16K x 16K pixels, because this would
already exhaust the 2 GByte address space limit of 32 bit systems.
Remove this limit on 64 bit systems to allow the full 32K x 32K size.
BUG: 391970
Differential Revision: https://phabricator.kde.org/D12557
Frameworks have a convention of naming uninstalled headers in src/ with
a _p at the end of the name, to make it clear they are not part of the
API. None of the headers in KImageFormats are installed, so it is not
really necessary to follow this convention, but we follow it anyway for
the benefit of both humans and tools (like kapidox).
