Large image dimensions make thumbnail fails and application to restart

[bjarnef]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

12.3.7

Bug summary

On an Umbraco Cloud project using Umbraco v12.3.7 the content editor has uploaded a PNG icon.
The icon/file itself wasn't large | 1.89 MB, but the image dimensions was 20833 x 20833 px

I have attached the icon/image here: accomodation.zip

When accessing the folder listview the thumbnail wasn't shown and accessing this folder made the application to restart.

In the log it was showing a lot of these errors:

Delete the file from recycle bin upload throwed an error, but was successfully deleted including the physical file, which seems to cause these errors in log:

Specifics

No response

Steps to reproduce

Upload the attached image/file to a folder in media archive.
The media thumbnail may not be shown in the folder list view or from media picker depending on the memory available.

Expected result / actual result

No response

[github-actions]

Hi there @bjarnef!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[bjarnef]

@JimBobSquarePants @nul800sebastiaan could Umbraco with ImageSharp try parse meta data from image and maybe by default limit to a max width/height of image during upload?

In this specific case it didn't seem to have enough ressources to process to image and the application restarted each time GetBigThumbnail was requested. After removing the image everything is fine 🙂

Something like this:
https://aaronbos.dev/posts/iptc-metadata-csharp-imagesharp

[JimBobSquarePants]

You’re looking for Image.Identify

That will provide you with the image dimensions plus additional metadata without decoding the image pixels.

[bjarnef]

@JimBobSquarePants thanks 😊🙌

@nul800sebastiaan should we check for this here

Umbraco-CMS/src/Umbraco.Web.BackOffice/Controllers/ImagesController.cs

Line 92 in 0cf436f

and return NotFound() or should we handle this on upload?

[Migaroez]

I was not able to reproduce the locally, but a starter umbraco cloud error leads to this when trying to view the uploaded image's thumbnail, which since i uploaded it on the root now makes the site lock up every time i open the media section 🤦

System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
   at System.Runtime.InteropServices.Marshal.AllocHGlobal(IntPtr cb)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedMemoryHandle.AllocateHandle(Int32 lengthInBytes)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedMemoryHandle.Allocate(Int32 lengthInBytes)
   at SixLabors.ImageSharp.Memory.Internals.UnmanagedBuffer`1.Allocate(Int32 lengthInElements)
   at SixLabors.ImageSharp.Memory.UnmanagedMemoryAllocator.Allocate[T](Int32 length, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.MemoryGroup`1.Allocate(MemoryAllocator allocator, Int64 totalLengthInElements, Int32 bufferAlignmentInElements, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.UniformUnmanagedMemoryPoolMemoryAllocator.AllocateGroup[T](Int64 totalLength, Int32 bufferAlignment, AllocationOptions options)
   at SixLabors.ImageSharp.Memory.MemoryAllocatorExtensions.Allocate2D[T](MemoryAllocator memoryAllocator, Int32 width, Int32 height, Boolean preferContiguosImageBuffers, AllocationOptions options)
   at SixLabors.ImageSharp.ImageFrame`1..ctor(Configuration configuration, Int32 width, Int32 height, TPixel backgroundColor, ImageFrameMetadata metadata)
   at SixLabors.ImageSharp.ImageFrame`1..ctor(Configuration configuration, Int32 width, Int32 height, TPixel backgroundColor)
   at SixLabors.ImageSharp.ImageFrameCollection`1..ctor(Image`1 parent, Int32 width, Int32 height, TPixel backgroundColor)
   at SixLabors.ImageSharp.Image`1..ctor(Configuration configuration, Int32 width, Int32 height, ImageMetadata metadata)
   at SixLabors.ImageSharp.Formats.Png.PngDecoderCore.InitializeImage[TPixel](ImageMetadata metadata, FrameControl frameControl, Image`1& image)
   at SixLabors.ImageSharp.Formats.Png.PngDecoderCore.Decode[TPixel](BufferedReadStream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoderUtilities.Decode[TPixel](IImageDecoderInternals decoder, Configuration configuration, Stream stream, Func`3 largeImageExceptionFactory, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoderUtilities.Decode[TPixel](IImageDecoderInternals decoder, Configuration configuration, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.Png.PngDecoder.Decode[TPixel](PngDecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.Png.PngDecoder.Decode(PngDecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.SpecializedImageDecoder`1.Decode(DecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoder.<>c__DisplayClass3_0.<DecodeAsync>b__0(Stream s, CancellationToken ct)
   at SixLabors.ImageSharp.Formats.ImageDecoder.<>c__DisplayClass12_0`1.<WithSeekableMemoryStreamAsync>g__PeformActionAndResetPosition|0(Stream s, Int64 position, CancellationToken ct)
--- End of stack trace from previous location ---
   at SixLabors.ImageSharp.Formats.ImageDecoder.CopyToMemoryStreamAndActionAsync[T](DecoderOptions options, Stream stream, Func`4 action, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Formats.ImageDecoder.DecodeAsync(DecoderOptions options, Stream stream, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Image.WithSeekableStreamAsync[T](DecoderOptions options, Stream stream, Func`3 action, CancellationToken cancellationToken)
   at SixLabors.ImageSharp.Web.FormattedImage.LoadAsync(DecoderOptions options, Stream source)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.ProcessRequestAsync(ImageCommandContext imageCommandContext, IImageResolver sourceImageResolver, ImageContext imageContext, Boolean retry)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.ProcessRequestAsync(ImageCommandContext imageCommandContext, IImageResolver sourceImageResolver, ImageContext imageContext, Boolean retry)
   at SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware.Invoke(HttpContext httpContext, Boolean retry)
   at Umbraco.Forms.Web.HttpModules.ProtectFormUploadRequestsMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

So there are a few things that could be argued here.

1. It's a hardware limitation that the core can't know about
2. It's a user error, they should be trained to not upload unnecessary large images based on 1
3. The core handles the mediaUpload, so it should allow for extension points to enhance the behavior so 1 or 2 does not result in system failures.

The only thing we could do something about is the third argument, so I am wondering whether we should provide a FileUpload validator mechanism that lets you validate the content of the stream that will be persisted based on the filetype determined in the PostAddFile method 🤔 It would behave similar to IFileStreamSecurityAnalyzer.

I will take this up team.

Besides this, I still don't understand how the following examine error is being triggered on your end Invalid deletion count: 2 vs docCount=1 🤔

[bjarnef]

@Migaroez

1. It's a hardware limitation that the core can't know about

• Yes, but based on my investigations processing an image with such large image dimensions requires quite a lot resources and it think it is possible to see the CPU spike in this case. Should it by default use Image.Identify to check dimensions and have a default configuration? At least not try to generate thumbnail from the image.
  If there were multiple images in a folder which such dimensions, I guess it could be an issue with even more memory it the folder had 10 images like this.

2. It's a user error, they should be trained to not upload unnecessary large images based on 1

• Yes, and I am sure most developers have recommendation for content editors, but there it nothing preventing content editors from doing this. The file size isn't large itself, so content editors (who are often non-tech people) would need to know how to check image dimensions.
  An alternative could be so show an warning to content editor. In most cases there isn't a need to upload image with dimensions (width and/or height > 10000px).

3. The core handles the mediaUpload, so it should allow for extension points to enhance the behavior so 1 or 2 does not result in system failures.

• I think ideally it would be great to handle this in core and based on starter plan on Umbraco Cloud as (without deeper knowledge) I think there are probably most projects on this plan (or perhaps Standard)?

[AndyButland]

See also:

• High CPU usage and site crash when uploading or resizing large animated GIFs (v17.2.1) #21922
• Large GIFs cause Umbraco on Azure Web App to restart when resizing in media section #16940

[rbottema]

I see from the issue you've linked @rbottema that you have been looking into this in recent days - if you can bring suggestions or a PR for Umbraco that would allow some control of configuration over this, that would be appreciated.

I haven't had the time to look into this further, but based on my research so far, here are my thoughts:

• We can try to handle the OOM exceptions gracefully, perhaps in combination with the guardrails that ImageSharp is developing. However, it's not clear to me if the runtime can gracefully recover from such an exception and if so, where we'd do that. This may prevent the application from crashing, but of course does not prevent the underlying denial of service.
• We can guard against ImageSharp processing images that might consume too many resources. Some thoughts on that:
  • The Middleware provides little extension points for this (by design). OnParseCommandsAsync is already used by Umbraco to enforce maximum dimensions, and some logic could be here to guess memory usage and if so, strip all commands, causing ImageSharp processing to be skipped. I don't think using Image.Identify is feasible here. There is also OnBeforeLoadAsync, where could do things like limit frames processed, but still requires either loading the image again through Image.Identify (the stream is not provided to the event) or rough guesswork based on the provided arguments.
  • We can have own middleware before ImageSharp, but this inevitably leads to duplicated logic, requesting images multiple times across the request, etc.
  • I don't think this is the way to go, as it seems to cause unexpected behavior, seems unreliable and/or can lead to performance implications. However, this might be an option for the backoffice, as Umbraco is in full control of the pipeline here and performance is less of a concern over stability.
• We can guard against generating URLs that would cause undesired processing. This can work if we do some checks on GetCropUrl in combination with ensuring HMAC is enabled. This will need to be done in a smart way to avoid performance implications.
• We can guard against having potentially problematic images at all, by doing the Image.Identify check against some configurable limit when editors upload media. It's likely still weird for the editor to have their 512 KB GIF file be rejected because it's too large, but at least it prevents any issues. This is what ImageSharp recommends (or at least, that is my interpretation). Of course some approach is needed to deal with all existing media (which is complicated by not being able to open the media in the backoffice).