gdk-pixbuf/gdk-pixbuf-enum-types.c.template | 10 6 + 4 - 0 !
1 file changed, 6 insertions(+), 4 deletions(-)

 make enum gtype registration thread safe

Use g_once_init_enter/leave to ensure that enumeration types can be
registered across threads.

tests/test-common.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 tests: fix some memory leaks

This is enough to make many of the tests pass under gcc's
AddressSanitizer. pixbuf-randomly-modified still fails when it cannot
allocate more memory, and pixbuf-fail fails with memory allocation
errors unless run with ASAN_OPTIONS=allocator_may_return_null=1.

Signed-off-by: Simon McVittie <smcv@debian.org>

po/ro.po | 455 223 + 232 - 0 !
1 file changed, 223 insertions(+), 232 deletions(-)

 update romanian translation

tests/meson.build | 45 23 + 22 - 0 !
1 file changed, 23 insertions(+), 22 deletions(-)

 build: do not install .test files when test is skipped

The skipping prevented the executable from being installed but not the .test file that referenced it.
This caused installed tests to fail:

	Running test: gdk-pixbuf/pixbuf-pixdata.test
	Caught exception during testing: Failed to execute child process ?/nix/store/kqmj2776mw24qxyswfbqlmybpws4g4yn-gdk-pixbuf-2.42.0-installedTests/libexec/installed-tests/gdk-pixbuf/pixbuf-pixdata? (No such file or directory)

gdk-pixbuf/io-gif.c | 27 14 + 13 - 0 !
1 file changed, 14 insertions(+), 13 deletions(-)

 gif: do all of gif_init() with a single read

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>

tests/meson.build | 5 1 + 4 - 0 !
1 file changed, 1 insertion(+), 4 deletions(-)

 tests: don't check whether bmp and gif loaders are enabled

This is conceptually similar to commit 2fd7d21f "tests: Fix GIF tests
being permanently disabled". One way or another, gdk-pixbuf always
supports these two formats: on Windows with the native gdiplus loader
enabled, it covers these two formats; otherwise, format-specific loaders
are used.

This means we will run the GIF tests, as intended.

Fixes: 7f0b214a "tests: Conditionally build and run tests"
Signed-off-by: Simon McVittie <smcv@debian.org>

tests/meson.build | 1 0 + 1 - 0 !
tests/pixbuf-jpeg.c | 6 6 + 0 - 0 !
2 files changed, 6 insertions(+), 1 deletion(-)

 skip test for gnome#753605

It relies on a non-free JPEG that happens to exhibit the bug, which is
excluded from the Debian source package.

tests/meson.build | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 tests: mark pixbuf-randomly-modified as flaky

This is basically a crude fuzzer. It isn't really suitable for
build-time acceptance testing, since it frequently produces images for
which gdk-pixbuf will try to allocate more memory than is available,
but if it does, it isn't straightforward to capture the failing image
from an autobuilder that only records build logs.

Bug: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/146
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942124
Signed-off-by: Simon McVittie <smcv@debian.org>

gdk-pixbuf/io-gif-animation.c | 21 13 + 8 - 0 !
1 file changed, 13 insertions(+), 8 deletions(-)

 gif: check for overflow when compositing or clearing frames.

gdk-pixbuf/lzw.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 add an assertion that checks for maximum lzw code size

gdk-pixbuf/io-gif.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 fix the check for maximum value of lzw initial code size.

gdk-pixbuf/io-ani.c | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

 ani: reject files with multiple anih chunks

An anih chunk causes us to initialize a bunch of state, which we only
expect to do once per file.

Fixes: #202
Fixes: CVE-2022-48622
(cherry picked from commit 00c071dd11f723ca608608eef45cb1aa98da89cc)

tests/test-images/fail/CVE-2022-48622.ani was committed separately
to allow this patch to be text instead of binary

gdk-pixbuf/io-ani.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 ani: reject files with multiple inam or iart chunks

There should be at most one chunk each.  These would cause memory leaks
otherwise.

gdk-pixbuf/io-ani.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 ani: validate anih chunk size

Before reading a chunk, we verify that enough bytes are available to match
the chunk size declared by the file.  However, uniquely, the anih chunk
loader doesn't verify that this size matches the number of bytes it
actually intends to read.  Thus, if the chunk size is too small and the
file ends in the middle of the chunk, we populate some context fields with
stack garbage.  (But we'd still fail later on because the file doesn't
contain any images.)  Fix this.