* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
(cherry picked from commit 34ed3bad27)
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"
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.
Since QImage does sanity checking for overflows and stuff wrt.
dimensions and depth, check for QImage::isNull() as early as possible to
see if there's some funky business going on.
Also tried to add some checks wherever we wrote to "raw" memory.
Unit tests pass, and tested converting some files from
https://samples.ffmpeg.org/image-samples/ to pngs, and that seemed to
work.
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D24367
Summary:
Make sure whole of pixel_size in pixel has data either because it was
read or because we set it to 0
oss-fuzz/14565
Reviewers: dfaure, apol, vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23739
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
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).
