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 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