Search for packages
| purl | pkg:nuget/Magick.NET-Q8-OpenMP-x64@14.10.2 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-569d-6nue-5kbq | ImageMagick releases an invalid pointer in BilateralBlur when memory allocation fails The BilateralBlurImage method will allocate a set of double buffers inside AcquireBilateralTLS. But the last element in the set is not properly initialized. This will result in a release of an invalid pointer inside DestroyBilateralTLS when the memory allocation fails. |
CVE-2026-22770
GHSA-39h3-g67r-7g3c |
| VCID-6meg-yjby-a7gj | ImageMagick has a Memory Leak in LoadOpenCLDeviceBenchmark() when parsing malformed XML ### Summary A memory leak vulnerability exists in the `LoadOpenCLDeviceBenchmark()` function in `MagickCore/opencl.c`. When parsing a malformed OpenCL device profile XML file that contains `<device` elements without proper `/>` closing tags, the function fails to release allocated memory for string members (`platform_name`, `vendor_name`, `name`, `version`), leading to memory leaks that could result in resource exhaustion. **Affected Version**: ImageMagick 7.1.2-12 and possibly earlier versions --- ### Details The vulnerability is located in `MagickCore/opencl.c`, function `LoadOpenCLDeviceBenchmark()` (lines 754-911). **Root Cause Analysis:** 1. When a `<device` tag is encountered, a `MagickCLDeviceBenchmark` structure is allocated (line 807-812) 2. String attributes (`platform`, `vendor`, `name`, `version`) are allocated via `ConstantString()` (lines 878, 885, 898, 900) 3. These strings are **only freed** when a `/>` closing tag is encountered (lines 840-849) 4. At function exit (lines 908-910), only the `device_benchmark` structure is freed, but **its member variables are not freed** if `/>` was never parsed **Vulnerable Code (lines 908-910):** ```c token=(char *) RelinquishMagickMemory(token); device_benchmark=(MagickCLDeviceBenchmark *) RelinquishMagickMemory( device_benchmark); // BUG: members (platform_name, vendor_name, name, version) not freed! ``` **Correct cleanup (only executed when `/>` is found, lines 840-849):** ```c device_benchmark->platform_name=(char *) RelinquishMagickMemory(device_benchmark->platform_name); device_benchmark->vendor_name=(char *) RelinquishMagickMemory(device_benchmark->vendor_name); device_benchmark->name=(char *) RelinquishMagickMemory(device_benchmark->name); device_benchmark->version=(char *) RelinquishMagickMemory(device_benchmark->version); device_benchmark=(MagickCLDeviceBenchmark *) RelinquishMagickMemory(device_benchmark); ``` --- ### PoC **Environment:** - OS: Ubuntu 22.04.5 LTS (Linux 6.8.0-87-generic x86_64) - Compiler: GCC 11.4.0 - ImageMagick: 7.1.2-13 (commit `a52c1b402be08ef8ae193f28ac5b2e120f2fa26f`) **Step 1: Build ImageMagick with AddressSanitizer** ```bash cd ImageMagick ./configure \ CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" \ CXXFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" \ LDFLAGS="-fsanitize=address" \ --disable-openmp make -j$(nproc) ``` **Step 2: Create malformed XML file** **Step 3: Place file in OpenCL cache directory** ```bash mkdir -p ~/.cache/ImageMagick cp malformed_opencl_profile.xml ~/.cache/ImageMagick/ImagemagickOpenCLDeviceProfile.xml ``` **Step 4: Run ImageMagick with leak detection** ```bash export ASAN_OPTIONS="detect_leaks=1:symbolize=1" ./utilities/magick -size 100x100 xc:red output.png ``` **ASAN Output:** ``` ================================================================= ==2543490==ERROR: LeakSanitizer: detected memory leaks Direct leak of 96 byte(s) in 2 object(s) allocated from: #0 ... in AcquireMagickMemory MagickCore/memory.c:536 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:807 Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:878 ← name Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:885 ← platform_name Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:898 ← vendor_name Direct leak of 15 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:900 ← version SUMMARY: AddressSanitizer: 203 byte(s) leaked in 18 allocation(s). ``` --- ### Impact **Vulnerability Type:** CWE-401 (Missing Release of Memory after Effective Lifetime) **Severity:** Low **Who is impacted:** - Users who have OpenCL enabled in ImageMagick - Systems where an attacker can place or modify files in the OpenCL cache directory (`~/.cache/ImageMagick/`) - Long-running ImageMagick processes or services that repeatedly initialize OpenCL **Potential consequences:** - Memory exhaustion over time if the malformed configuration is repeatedly loaded - Denial of Service (DoS) in resource-constrained environments **Attack Vector:** Local - requires write access to the user's OpenCL cache directory |
GHSA-qp59-x883-77qv
|
| VCID-h221-qd8d-tqa5 | ImageMagick has a NULL pointer dereference in MSL parser via <comment> tag before image load ## Summary NULL pointer dereference in MSL (Magick Scripting Language) parser when processing `<comment>` tag before any image is loaded. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:poc.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer poc.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer poc.msl ``` ## Expected Behavior ImageMagick should handle the malformed MSL gracefully and return an error message. ## Actual Behavior ``` convert: MagickCore/property.c:297: MagickBooleanType DeleteImageProperty(Image *, const char *): Assertion `image != (Image *) NULL' failed. Aborted ``` ## Root Cause Analysis In `coders/msl.c:7091`, `MSLEndElement()` calls `DeleteImageProperty()` on `msl_info->image[n]` when handling the `</comment>` end tag without checking if the image is NULL: ```c if (LocaleCompare((const char *) tag,"comment") == 0 ) { (void) DeleteImageProperty(msl_info->image[n],"comment"); // No NULL check ... } ``` When `<comment>` appears before any `<read>` operation, `msl_info->image[n]` is NULL, causing the assertion failure in `DeleteImageProperty()` at `property.c:297`. ## Impact - **DoS**: Crash via assertion failure (debug builds) or NULL pointer dereference (release builds) - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
CVE-2026-23952
GHSA-5vx3-wx4q-6cj8 |
| VCID-vaks-d4k5-zue7 | ImageMagick MSL: Stack overflow via infinite recursion in ProcessMSLScript ## Summary Stack overflow via infinite recursion in MSL (Magick Scripting Language) `<write>` command when writing to MSL format. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD - Requires: libxml2 support (for MSL parsing) ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:recursive.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer recursive.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer recursive.msl ``` ## Expected Behavior ImageMagick should handle recursive MSL references gracefully by detecting the loop and returning an error. ## Actual Behavior Stack overflow causes process crash: ``` AddressSanitizer:DEADLYSIGNAL ==PID==ERROR: AddressSanitizer: stack-overflow #0 MSLStartElement /src/imagemagick/coders/msl.c:7045 #1 xmlParseStartTag /src/libxml2/parser.c #2 xmlParseChunk /src/libxml2/parser.c:11273 #3 ProcessMSLScript /src/imagemagick/coders/msl.c:7405 #4 WriteMSLImage /src/imagemagick/coders/msl.c:7867 #5 WriteImage /src/imagemagick/MagickCore/constitute.c:1346 #6 MSLStartElement /src/imagemagick/coders/msl.c:7045 ... (infinite recursion, 287+ frames) ``` ## Root Cause Analysis In `coders/msl.c`, the `<write>` command handler in `MSLStartElement()` (line ~7045) calls `WriteImage()`. When the output filename specifies MSL format (`msl:filename`), `WriteMSLImage()` is called, which parses the MSL file again via `ProcessMSLScript()`. If the MSL file references itself (directly or indirectly), this creates an infinite recursion loop: ``` MSLStartElement() → WriteImage() → WriteMSLImage() → ProcessMSLScript() → xmlParseChunk() → MSLStartElement() → ... (infinite loop) ``` ## Impact - **DoS**: Guaranteed crash via stack exhaustion - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Additional Trigger Paths The `<read>` command can also trigger recursion: Indirect recursion is also possible (a.msl → b.msl → a.msl). ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
CVE-2026-23874
GHSA-9vj4-wc7r-p844 |