GHSA-VF33-6R7X-66XX: Division by Zero and Integer Overflow in ImageMagick Morphology

ImageMagick exposes a morphology module designed to apply convolution kernels to images for operations like blurring, edge detection, and noise reduction. The library supports dynamically generated kernels, including binomial kernels, which rely on mathematical combinations to determine pixel weighting.

The generation of these binomial kernels requires the calculation of binomial coefficients, which internally depend on computing mathematical factorials. The function responsible for these factorial calculations operates on standard architecture-dependent integer types without bounds checking.

An integer overflow vulnerability, tracked as GHSA-VF33-6R7X-66XX, exists within this specific calculation path. When the software processes a request for a binomial kernel with a large radius, the factorial calculation exceeds the maximum bounds of the underlying integer type.

This initial integer overflow triggers a secondary flaw where the mathematical operations yield a zero denominator. The subsequent division by zero results in a fatal arithmetic exception (SIGFPE), causing the immediate termination of the ImageMagick process and presenting a denial-of-service vector.

The root cause originates in the fact() inline function located in MagickCore/morphology.c. This helper function calculates the factorial of a given integer n using a standard iterative loop that stores the accumulated product in a size_t variable.

Factorial growth is strictly non-linear and scales rapidly, quickly exceeding standard integer limits. On a 64-bit architecture, the maximum representable value for a size_t is approximately 1.84 x 10^19. The factorial of 21 exceeds this boundary, resulting in a silent integer wrap-around. On 32-bit systems, the overflow occurs much earlier at the factorial of 13.

The binomial kernel algorithm calculates matrix weights using the standard formula. When the order n reaches a high enough value, the accumulated multiplication in fact() gathers sufficient factors of 2. In modular arithmetic constrained by base-2 integer sizes (e.g., modulo 2^64), accumulating at least 64 factors of 2 guarantees that the resulting product evaluates exactly to zero.

When fact() returns zero for elements of the denominator, the algorithm attempts a division operation against this result. The CPU raises a floating-point exception for division by zero, terminating the process ungracefully since ImageMagick does not catch and recover from synchronous arithmetic exceptions in this module.

Analysis of MagickCore/morphology.c reveals the exact progression of the defect. The vulnerable fact() implementation performs unbounded multiplication. The AcquireKernelBuiltIn() function calls fact() directly with user-influenced arguments derived from the kernel radius.

/* Vulnerable implementation snippet */
static inline size_t fact(size_t n) {
  size_t f, l;
  for(f=1, l=2; l <= n; f=f*l, l++);
  return(f);
}

This function lacks safety mechanisms to verify if the product operation will exceed SIZE_MAX.

The patch implemented in commit d67eef71764cfeca07b4edf8a8ae922180f5f2e4 addresses the vulnerability by enforcing strict mathematical limits on the kernel order before any factorial computation occurs. The maintainers introduced a dynamic constant max_order that limits the input bounds based on the architecture's size_t width.

/* Patched implementation snippet in morphology.c */
case BinomialKernel:
  {
    const size_t max_order = (sizeof(size_t) > 4) ? 20 : 12;
    size_t order_f;
 
    /* Check if kernel order (width-1) would overflow fact() */
    if ((kernel->width-1) > max_order)
      return(DestroyKernelInfo(kernel));
 
    order_f = fact(kernel->width-1);
  }

By restricting the maximum order to 20 on 64-bit systems and 12 on 32-bit systems, the application ensures that the highest possible calculation never exceeds the arithmetic bounds.

Understanding the execution path illustrates how user-controlled data traverses the application to cause the denial of service. The vulnerability path strictly involves the morphology module and internal math functions.

This flow explicitly shows the lack of boundary validation between the kernel width assignment and the factorial computation. The direct propagation of the unvalidated width dictates the arithmetic failure.

Exploitation of GHSA-VF33-6R7X-66XX does not require advanced memory corruption techniques. The trigger is entirely deterministic and relies strictly on providing a large radius parameter to the morphology subsystem. An attacker invokes the binomial kernel generation routine with an excessively large argument.

A minimal proof-of-concept requires invoking the ImageMagick command-line interface with the -morphology or -convolve flags. Passing a parameter string such as Binomial:100 forces the application to calculate the kernel with an order well beyond the overflow threshold.

# Deterministic trigger causing a SIGFPE crash
magick input.png -morphology Binomial:100 output.png

This command instructs the morphology engine to acquire a built-in kernel of type Binomial with a radius of 100, which invariably hits the integer wrap-around and division by zero.

For applications utilizing Magick.NET, the vulnerability manifests similarly if user input dictates the morphology parameters. An attacker interacting with a web endpoint that processes images and blindy accepts morphology options can send identical malicious values, terminating the hosting application pool.

The vulnerability yields a direct denial-of-service condition. Because the division by zero triggers a hardware-level SIGFPE, the host operating system instantly halts the vulnerable process. There is no memory corruption, memory leak, or instruction pointer hijacking associated with this flaw.

The security impact is classified as Low severity because triggering the vulnerability requires specific conditions. An attacker must have the ability to supply arbitrary command-line arguments to the ImageMagick binary or control the morphology kernel parameters in an API call.

Web applications that allow user uploads but do not expose raw processing parameters remain unaffected by this specific vector. The flaw cannot be triggered merely by parsing a malformed image format; the attack requires injecting arguments into the image processing pipeline configuration.

In shared hosting environments or microservices that rely heavily on ImageMagick for backend processing, continuous exploitation of this flaw can exhaust process supervisors. An attacker repeatedly submitting malicious morphology requests will force the application server to continuously restart worker processes, degrading service availability.

The primary and complete remediation strategy is to update the ImageMagick suite to version 7.1.1-33 or later. This release incorporates the strict max_order bounds checking in the binomial kernel allocation logic, entirely eliminating the integer overflow vector.

Developers utilizing Magick.NET in C# environments must update their NuGet packages to the releases corresponding with ImageMagick 7.1.1-33. Verifying the library dependency tree is necessary to ensure older, static builds of the core library are not inadvertently packaged with the application.

If immediate patching is not possible, system administrators can mitigate the risk through strict input validation. Applications that expose ImageMagick processing capabilities to end-users must sanitize and restrict all morphology parameters. Enforcing a hard limit on kernel radius values prevents the mathematical trigger condition.

Security engineering teams should implement monitoring for abnormal application crashes containing SIGFPE signals. Correlating these crash dumps with incoming user processing requests can identify active denial-of-service attempts targeting the morphology module.