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 XMP profile write that triggers hang due to unbounded loop
### Summary
Infinite lines occur when writing during a specific XMP file conversion command
### Details
```
#0  GetXmpNumeratorAndDenominator (denominator=<optimized out>, numerator=<optimized out>, value=<optimized out>) at MagickCore/profile.c:2578
#1  GetXmpNumeratorAndDenominator (denominator=<synthetic pointer>, numerator=<synthetic pointer>, value=720000000000000) at MagickCore/profile.c:2564
#2  SyncXmpProfile (image=image@entry=0x555555bb9ea0, profile=0x555555b9d020) at MagickCore/profile.c:2605
#3  0x00005555555db5cf in SyncImageProfiles (image=image@entry=0x555555bb9ea0) at MagickCore/profile.c:2651
#4  0x0000555555798d4f in WriteImage (image_info=image_info@entry=0x555555bc2050, image=image@entry=0x555555bb9ea0, exception=exception@entry=0x555555b7bea0) at MagickCore/constitute.c:1288
#5  0x0000555555799862 in WriteImages (image_info=image_info@entry=0x555555bb69c0, images=<optimized out>, images@entry=0x555555bb9ea0, filename=<optimized out>, exception=0x555555b7bea0) at MagickCore/constitute.c:1575
#6  0x00005555559650c4 in CLINoImageOperator (cli_wand=cli_wand@entry=0x555555b85790, option=option@entry=0x5555559beebe "-write", arg1n=arg1n@entry=0x7fffffffe2c7 "a.mng", arg2n=arg2n@entry=0x0) at MagickWand/operation.c:4993
#7  0x0000555555974579 in CLIOption (cli_wand=cli_wand@entry=0x555555b85790, option=option@entry=0x5555559beebe "-write") at MagickWand/operation.c:5473
#8  0x00005555559224aa in ProcessCommandOptions (cli_wand=cli_wand@entry=0x555555b85790, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, index=index@entry=1) at MagickWand/magick-cli.c:758
#9  0x000055555592276d in MagickImageCommand (image_info=image_info@entry=0x555555b824a0, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, metadata=metadata@entry=0x7fffffffbc10, exception=exception@entry=0x555555b7bea0) at MagickWand/magick-cli.c:1392
#10 0x00005555559216a0 in MagickCommandGenesis (image_info=image_info@entry=0x555555b824a0, command=command@entry=0x555555922640 <MagickImageCommand>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, metadata=0x0, exception=exception@entry=0x555555b7bea0) at MagickWand/magick-cli.c:177
#11 0x000055555559f76b in MagickMain (argc=3, argv=0x7fffffffdfa8) at utilities/magick.c:162
#12 0x00007ffff700fd90 in __libc_start_call_main (main=main@entry=0x55555559aec0 <main>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8) at ../sysdeps/nptl/libc_start_call_main.h:58
#13 0x00007ffff700fe40 in __libc_start_main_impl (main=0x55555559aec0 <main>, argc=3, argv=0x7fffffffdfa8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdf98) at ../csu/libc-start.c:392
#14 0x000055555559f535 in _start ()
```
```
static void GetXmpNumeratorAndDenominator(double value,
  unsigned long *numerator,unsigned long *denominator)
{
  double
    df;

  *numerator=0;
  *denominator=1;
  if (value <= MagickEpsilon)
    return;
  *numerator=1;
  df=1.0;
  while(fabs(df - value) > MagickEpsilon)
  {
    if (df < value)
      (*numerator)++;
    else
      {
        (*denominator)++;
        *numerator=(unsigned long) (value*(*denominator));
      }
    df=*numerator/(double)*denominator;
  }
}
```
In this code, the loop `while(fabs(df - value) > MagickEpsilon)` keeps repeating endlessly.

### PoC
`magick hang a.mng`
https://drive.google.com/file/d/1iegkwlTjqnJTtM4XkiheYsjKsC6pxtId/view?usp=sharing

### Impact
XMP profile write triggers hang due to unbounded loop


### credits
**Team Pay1oad DVE** 

**Reporter** :  **Shinyoung Won** (with contributions from **WooJin Park, DongHa Lee, JungWoo Park, Woojin Jeon, Juwon Chae**, **Kyusang Han, JaeHun Gou**)

**yosimich(@yosiimich**) **Shinyoung Won** of SSA Lab

e-mail : [yosimich123@gmail.com]

**Woojin Jeon**

Gtihub : brainoverflow

e-mail : [root@brainoverflow.kr]

**WooJin Park**

GitHub : jin-156

e-mail : [1203kids@gmail.com]

**Who4mI(@GAP-dev) Lee DongHa of SSA Lab**

Github: GAP-dev

e-mail : [ceo@zeropointer.co.kr]

**JungWoo Park**

Github : JungWooJJING

e-mail : [cuby5577@gmail.com]

**Juwon Chae** 

Github : I_mho

e-mail : [wndnjs4698@naver.com]

**Kyusang Han**

Github : T1deSEC

e-mail : [hksjoe0081@gmail.com]

**JaeHun Gou**

Github : P2GONE

e-mail : [charly20@naver.com]

### Commits
Fixed in: https://github.com/ImageMagick/ImageMagick/commit/229fa96a988a21d78318bbca61245a6ed1ee33a0 and https://github.com/ImageMagick/ImageMagick/commit/38631605e6ab744548a561797472cf8648bcfe26

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