Search for packages
| purl | pkg:nuget/Magick.NET-Q8-OpenMP-x64@14.7.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-5s8n-dfjf-ruey | 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. |
CVE-2025-53014
GHSA-hm4x-r5hc-794f |
| VCID-6t7d-2hre-sqbw | 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 |
CVE-2025-53015
GHSA-vmhh-8rxq-fp9g |
| VCID-784p-34mz-vucz | 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 |
CVE-2025-53019
GHSA-cfh4-9f7v-fhrc |
| VCID-9ewm-6688-kkar | 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 |
CVE-2025-53101
GHSA-qh3h-j545-h8c9 |