Package Instance

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.

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

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

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