Source: tiff
Version: 4.7.0-3+deb13u1
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
1. Save 16 bit TIFF file from Canon DPP on macOS
2. on Debian Trixie: cd to SMB share on macOS machine
3. on macOS, using XQuartz as Xserver
4. On Debian Trixie, gimp --display=localhost:10.0 ./IMG_4758cs.TIF
5. Gimp appears to take forever to load file and begins using swap
* What exactly did you do (or not do) that was effective (or
ineffective)?
Tried version of Gimp without the fix for CVE-2025-9900
Tried versions of GraphicMagick with and without fix for CVE-2025-9900
* What was the outcome of this action?
Problem started with fix for CVE-2025-9900
* What outcome did you expect instead?
I expected the file to load for editing as it did before the fix for
CVE-2025-9900
*** End of the template - remove these template lines ***
By trying to allocate infinite memory, tiff slows down the computer.
It has been many decades since I read the TIFF standards, but I seem to
remember the use of
0xFFFFFFFF, maximum unsigned integer, as marker for no value and not a valid
number.
I expect the Canon software has not changed in a very long time and that the
tiff
files it created were considered valid at the time.
https://lists.debian.org/debian-security-announce/2025/msg00189.html
https://security-tracker.debian.org/tracker/CVE-2025-9900
https://gitlab.com/libtiff/libtiff/-/issues/704
-- System Information:
Debian Release: 13.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.48+deb13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
