| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As documented in the introductory comment, the interface of the various
functions in the GIF loader is that they read all the bytes they need,
or return -1 if not enough are available. Since commit
5212d69f "gif: Replace old buffer management code with GByteArray",
the incremental loader strictly depends on that assumption.
Unfortunately, gif_init() didn't conform to that interface. If there
were enough bytes available for the GIF signature (GIF87a or GIF89a)
but not enough bytes for the screen descriptor, it would return -1
having already consumed the first 6 bytes of the stream. A subsequent
retry with more data available would start from the beginning of the
screen descriptor, and immediately raise an error because the screen
descriptor is extremely unlikely to start with another copy of the
"GIF8" magic number.
The regression test tests/pixbuf-short-gif-write.c would have detected
this, but was accidentally disabled by commit 7f0b214a "tests:
Conditionally build and run tests".
This seems most easily fixed by reading the whole of the 13-byte
fixed-length header in one go. Adjust the offsets into the buffer
used to parse the screen descriptor accordingly.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
|
| |
Use g_once_init_enter/leave to ensure that enumeration types can be
registered across threads.
|
|
|
|
|
|
|
|
|
| |
The code value after a reset wasn't being validated, which means we would
accept invalid codes. This could cause an infinite loop in the decoder.
Fixes CVE-2020-29385
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/164
|
|
|
|
|
|
|
|
| |
as the background.
This was a regression introduced in 5212d69f2362f9b68ccf9385277e5c4a744b2187.
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/162
|
|
|
|
| |
We must handle the error path, where the out argument isn't set.
|
| |
|
|
|
|
|
| |
Iterate over the key/value arrays once, using GArray to store the text
chunks after validating the keys.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
gif: Fix bug where the local colormap is not dropped.
Closes #156
See merge request GNOME/gdk-pixbuf!79
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was seen in a GIF file that had a local colormap set on frame 6, but not
on frame 7. Instead of reverting to the global colormap we continued to render
with the last local colormap.
This was a regression introduced in 4e7b5345d2fc8f0d1dee93d8ba9ab805bc95d42f.
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/156
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
| |
This is expected by the loader API which trips over an assertion otherwise.
Partially loaded images still work while images that are too truncated
fail gracefully.
Fixes #111.
|
|
|
|
| |
This is more consistent with other modules like GTK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libjasper is not really maintained any more, and has been dropped by
various Linux distributions over the years.
GdkPixbuf has not enabled the JPEG2000 loader by default in many years,
relying on downstream distributors to do so if they also shipped
libjasper. This means that it's unlikely anybody has relied on GdkPixbuf
to load a JPEG2000 image for the past 3 to 5 years, if at all.
The only other option for loading JPEG2000 images is to use OpenJPEG,
and for that there is an out of tree GdkPixbuf module available:
https://notabug.org/necklace/jp2-pixbuf-loader
Fixes: #152, #137
|
|
|
|
|
|
|
|
|
|
|
| |
This patch significantly improves performance
of gtksourceview-2.10.5 full-screen redraw
on a 4K display with an alpha channel.
Divisions by the common value 0xff0000 are converted into
multiplications by an optimizing C compiler.
For other values, 3 divisions are reduced to 1 division,
3 multiplications and some float-to-int conversions.
|
|
|
|
|
|
|
| |
The relative links in the functions documentation stanza refer to the
current section; this means that, in order to refer to an anchor
specified in a section the symbols must be in the same section within
the same file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pixel data in XPM files consists of color characters.
XPM allows up to 31 characters per pixel (cpp). If the file defines
a width larger than G_MAXINT / cpp, the calculated memory required
to parse a single line (wbytes) leads to a signed integer overflow.
On common systems, a signed integer overflow works as expected on
a bit level. Properly crafted files can overflow the variable
wbytes in a way that it is positive again, which leads to a
"successful" parsing of the XPM file. The pixel values itself are
not assigned by gdk-pixbuf code, therefore leaking raw memory
returned by malloc.
This might leak sensitive information through pixel values,
depending on the actual application.
Proof of Concept:
/* XPM */
static char * poc_xpm[] = {
"138547333 1 1 31",
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c None",
"---------------------------"};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parsing an XBM file with pixel bits larger than int leads to undefined
behavior (signed integer overflow).
Since only the lowest 8 bits are used, this patched code produces the
same images as before.
Also do not increment gotone but set it to a value. If more than
INT_MAX values are parsed, this int would overflow as well.
Proof of Concept (compile with -fsanitize=undefined or -ftrapv):
static unsigned char poc_bits[] = {
0xFFFFFFFF };
|
|
|
|
|
| |
Avoid declaring variables in a for loop initialization so that the code
continues to build on older compilers.
|
|
|
|
|
|
| |
The get_static_image() method for gifs is leaking an iterator and since
the iterator has a reference to the animation, this results in all
animation frames being leaked.
|
|
|
|
|
|
| |
Avoid overflows by using the checked multiplication macro for gsize.
Fixes: #132
|
|
|
|
|
| |
We might still get a GdkPixbuf even if the GError is set, which leads to
us reusing the GError instance later on.
|
|
|
|
|
|
|
| |
Previously only skipped bytes at the start of incremental
loads. During a incremental load, there may be bytes to skip
between reloads. Previous behavior misread metadata sometimes.
Fixes #70
|
|
|
|
|
|
|
|
|
| |
They were prepare_func/prepared_func, and update_func/updated_func in
various places.
Since their corresponding type names are GdkPixbufModulePreparedFunc
and GdkPixbufModuleUpdatedFunc, make all the fields be called
prepared_func and updated_func to make them easier to grep.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This will let us avoid NULL checks in the individual modules.
|
|
|
|
|
| |
Also remove redundant null checks before g_free, and use g_free instead
of g_clear_pointer because we never read the pointer value again.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Changed variable to unsigned and slightly improved algorithm performance
(stop when n == 0, no need to keep going until the end).
See issue: #96
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes build failure of:
../gdk-pixbuf/io-gif-animation.c: In function ‘gdk_pixbuf_gif_anim_iter_get_pixbuf’:
../gdk-pixbuf/io-gif-animation.c:418:17: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration]
418 | memset (gdk_pixbuf_get_pixels (anim->last_frame_data), 0, gdk_pixbuf_get_rowstride (anim->last_frame_data) * anim->height);
| ^~~~~~
../gdk-pixbuf/io-gif-animation.c:418:17: warning: incompatible implicit declaration of built-in function ‘memset’
../gdk-pixbuf/io-gif-animation.c:28:1: note: include ‘<string.h>’ or provide a declaration of ‘memset’
27 | #include "lzw.h"
+++ |+#include <string.h>
28 |
../gdk-pixbuf/io-gif-animation.c:443:33: warning: incompatible implicit declaration of built-in function ‘memset’
443 | memset (line, 0, (x_end - anim->last_frame->x_offset) * 4);
| ^~~~~~
../gdk-pixbuf/io-gif-animation.c:443:33: note: include ‘<string.h>’ or provide a declaration of ‘memset’
cc1: some warnings being treated as errors
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If one does a plain
GdkPixbuf *pixbuf = g_object_new (GDK_TYPE_PIXBUF, NULL);
Then all the construct properties use their default values. This
means that both "pixels" and "pixel-bytes" get passed as NULL to
gdk_pixbuf_set_property().
Later, trying to get the property for "pixel-bytes" would assert,
incorrectly, because it was trying to create a GBytes from a NULL
pixels storage.
This commit adds a test for that construction case, and tests for
constructing with g_object_new() in general.
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/91
|
| |
|
| |
|