Jpeg decoder can lead to finalizer memory leaks with specific malformed images

[br3aker]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

ImageSharp version

Current main branch

Other ImageSharp packages and versions

None

Environment (Operating system, version and so on)

Windows 10

.NET Framework version

Any supported

Description

Jpeg decoder can leak IDisposable memory wrapper to the finalizer, no memory is actually leaked this way but MemoryDiagnostics reports this as a leak even with proper exception handling via try/catch;

Current decoding pipeline:

1. Gather jpeg info (components, tables, frame size, etc.) <- pixel buffer is allocated here
2. For each scan:
       For each mcu row:
           Decode: huffman -> spectral -> rgb -> TPixel
3. Create Image object using allocated pixel buffer

Any exceptions between step 1 and 3 would cause allocated pixel buffer to be gc'd leading to a false positive memory leak reported by memory diagnostics. Any invalid marker between scans can cause this, it shouldn't crash the entire process.

Steps to Reproduce

This code:

try
{
    using Image img = Image.Load(/* path to image */);
}
catch(Exception ex)
{
    Console.WriteLine($"{ex.GetType()}\n{ex.Message}");
}

GC.Collect();
Console.WriteLine(MemoryDiagnostics.TotalUndisposedAllocationCount);

With attached image prints:

SixLabors.ImageSharp.InvalidImageContentException
Multiple SOF markers. Only single frame jpegs supported.
1

Note that 1 at the end signaling that we have a single leaked memory resource which we can't resolve from user perspective.

Images

progressive_inter_scan_exception.zip

Attached image is a manually malformed progressive jpeg image with multiple scans, it contains second SOS marker right after the first scan which is considered a malformed jpeg. It doesn't contain any actual data after malformed marker to reduce test image size.

[JimBobSquarePants]

Ace. Thanks for raising this. I'm assuming you already have a solution in mind?

[br3aker]

It should be fairly simple, I'll create a PR soon (I hope, gotta finish that downscaling stuff).

[tocsoft]

I think this might be solved by #2082, we had cases in pretty much every decoder that would leak rented memory when exception where thrown during decode.

[br3aker]

Cool, thanks for fixing this and creating an API for testing! @tocsoft

[br3aker]

Closed by #2082.