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/meson.build | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 use the right gdk-pixbuf-query-loaders directory

Since the .install moves the binary to another location the .pc file
needs to be updated

tests/pixbuf-jpeg.c | 7 4 + 3 - 0 !
1 file changed, 4 insertions(+), 3 deletions(-)

 tests: tolerate either corrupt_image or insufficient_memory for
 issue 205

Workaround for https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/215

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

 lzw: fix reporting of bytes written in decoder

When the LZW decoder encounters an invalid code, it stops
processing the image and returns the whole buffer size.
It should return the amount of bytes written, instead.

Bug: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/257
Bug-CVE: https://security-tracker.debian.org/tracker/CVE-2025-6199
Bug-Debian: https://bugs.debian.org/1107994

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

 jpeg: be more careful with chunked icc data

We we inadvertendly trusting the sequence numbers not to lie.
If they do we would report a larger data size than we actually
allocated, leading to out of bounds memory access in base64
encoding later on.