A vulnerability has been reported in libpng, which can be exploited by malicious people to cause a DoS (Denial of Service).
The vulnerability is caused due to the library using large amount of CPU and memory resources when processing certain highly compressed ancillary chunks, which can be exploited to cause a DoS by tricking an application using the library into processing a specially crafted PNG file.
The vulnerability is reported in versions prior to 1.0.53, 1.2.43, and 1.4.1.
Update to version 1.0.53, 1.2.43, and 1.4.1 and follow the vendor's instructions to increase protection against the so called "decompression bombs":
Further details available in Customer Area
Provided and/or discovered by
Reported by the PNG Development Group after encountering a malformed image in the wild.
base-system, please provide an updated ebuild.
The png_decompress_chunk function in pngrutil.c in libpng 1.0.x
before 1.0.53, 1.2.x before 1.2.43, and 1.4.x before 1.4.1 does not
properly handle compressed ancillary-chunk data that has a
disproportionately large uncompressed representation, which allows
remote attackers to cause a denial of service (memory and CPU
consumption, and application hang) via a crafted PNG file, as
demonstrated by use of the deflate compression method on data
composed of many occurrences of the same character, related to a
"decompression bomb" attack.
libpng 1.2.43 now in the tree
Adding tracker bug for >=media-libs/libpng-1.4.0 problems.
Only 308617 is left there, can someone fix that or might it still be OK to go stable with 1.2.43?
amd64 and x86 should stabilize this for binary packages for use with libpng-1.4:
media-libs/libpng-1.2.43-r1 -> amd64 x86
everyone should mark this stable, normal libpng ebuild,
media-libs/libpng-1.2.43-r2 -> alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86
Stable for HPPA.
Marked ppc stable.
Should the 1.2.43-r2 ebuild be slotted for "1.2" instead of "0" ?
GLSA with #324153