Package: libgdk-pixbuf-2.0-0 Version: 2.42.12+dfsg-3 Severity: important Tags: security upstream moreinfo help X-Debbugs-Cc: Debian Security Team <t...@security.debian.org>, debian-...@lists.debian.org Forwarded: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/249 Control: fixed -1 2.42.12+dfsg-4
I happened to notice that a buffer overflow was reported and fixed upstream, involving parsing a JPEG file with multiple chunks of embedded ICC colour-correction data. (It has not been fixed in a release, only in the upstream development branch.) The buffer overflow was discovered by OSS-Fuzz, using an out-of-tree fuzzing driver running on a customized version of Ubuntu 20.04 with instrumented, AddressSanitizer'ized versions of GLib and gdk-pixbuf, and it doesn't seem like the reproducer is necessarily a simple JPEG file that can be loaded manually - as with many fuzzing-based CVEs, the reporter is assuming that everyone knows how their elaborate fuzzing machinery works. Since uploading the fixed version to unstable, we've had a report of a regression, https://bugs.debian.org/1109199, which I forwarded upstream as https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/262. I cannot reproduce the regression, and the regression reporter has not provided enough details to make it actionable - I suspect that they might have a JPEG image containing very specific ICC data which triggers some related bug. (Or it might be user error - who can say?) I think we should probably leave this unfixed in stable and LTS for now, until we have a better idea of whether the regression is a real thing. cc -lts to warn off the LTS team from doing anything overzealous for now. I am by no means an expert on either the gdk-pixbuf codebase, the finer points of JPEG parsing, or reproducing fuzzer-generated crashes in a more reasonable environment, so I would very much appreciate it if someone who is better at those topics (and ideally someone who can spend their paid time on it!) can take it from here. Thanks, smcv
