From ${URL} : IMAGE_DIMENSIONS_OK ensures that image width and height are less then 46340, so that maximum number of pixels is ~2**31. Unfortunately, there are a lot of code that allocates image data with something like malloc(w * h * sizeof(DATA32)); Obviously, on 32-bit machines this results in integer overflow, insufficient heap allocation, with [massive] out-of-bounds heap overwrite. Either X_MAX should be reduced to 32767, or (w)*(h) should be checked to not exceed ULONG_MAX/sizeof(DATA32). Security implications: *) for 32-bit machines: insufficient heap allocation and heap overwrite in many image loaders, with escalation potential to remote code execution; *) for 64-bit machines: it seems, no impact. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
there's some other fixes going on in the git repo. probably want to just wait for 1.4.9 to roll all of them up.
1.4.9 is in the tree now. should be fine for stable.
Stable for PPC64.
Stable for HPPA.
amd64 stable
x86 stable
arm stable
Stable on alpha.
ppc stable
sparc stable
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
CVE-2016-4024 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-4024): Integer overflow in imlib2 before 1.4.9 on 32-bit platforms allows remote attackers to execute arbitrary code via large dimensions in an image, which triggers an out-of-bounds heap memory write operation.
New GLSA request filed.
This issue was resolved and addressed in GLSA 201611-12 at https://security.gentoo.org/glsa/201611-12 by GLSA coordinator Aaron Bauman (b-man).
