ImageSharp.Drawing crashes on malformed SVG path input (IOOB, ArithmeticException)

[pawlos]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp.Drawing
• 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.Drawing version

2.1.7 (latest stable on NuGet)

Other ImageSharp packages and versions

N/A

Environment (Operating system, version and so on)

Linux x64 (WSL2 / Ubuntu)

.NET Framework version

.NET 10.0

Description

Fuzzing ImageSharp.Drawing with AFL++ and SharpFuzz found 2 unique crashes triggered by malformed SVG path strings.

Crash 1 - IndexOutOfRangeException in ArcLineSegment constructor (89 bytes). SVG arc parameters with overflowing numeric values cause an unchecked array access.

Crash 2 - ArithmeticException in TopologyUtilities.GetPolygonOrientation (40 bytes). A malformed SVG arc with overflowing radius produces NaN coordinates that propagate through the geometry pipeline into Math.Sign(), which rejects NaN values.

Steps to Reproduce

using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Drawing;
using SixLabors.ImageSharp.Drawing.Processing;
using SixLabors.ImageSharp.PixelFormats;
using SixLabors.ImageSharp.Processing;

// Crash 1 — IOOB in ArcLineSegment (89 bytes)
var svg1 = "M 10 80 A 4444444444444444444444444444444444444445 45 0 04445 45 0 0 0 125 125 L 125 80 Z";

// Crash 2 — ArithmeticException from NaN (40 bytes)
var svg2 = "M 10 80 A 45 455555555555555555555555 55";

foreach (var (name, svg) in new[] { ("crash_1", svg1), ("crash_2", svg2) })
{
    try
    {
        if (SixLabors.ImageSharp.Drawing.Path.TryParseSvgPath(svg, out var path))
        {
            using var image = new Image<Rgba32>(100, 100);
            image.Mutate(ctx => ctx.Fill(Color.Red, path));
        }
        Console.WriteLine($"{name}: OK");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"{name}: {ex.GetType().Name} — {ex.Message}");
    }
}

Crash 1 stack trace:

System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at SixLabors.ImageSharp.Drawing.ArcLineSegment..ctor(PointF from, PointF to, SizeF radius, Single rotation, Boolean largeArc, Boolean sweep)
   at SixLabors.ImageSharp.Drawing.PathBuilder.AddArc(...)
   at SixLabors.ImageSharp.Drawing.Path.TryParseSvgPath(ReadOnlySpan`1 svgPath, IPath& value)

Crash 2 stack trace:

System.ArithmeticException: Function does not accept floating point Not-a-Number values.
   at System.Math.Sign(Single value)
   at SixLabors.ImageSharp.Drawing.Shapes.Helpers.TopologyUtilities.GetPolygonOrientation(ReadOnlySpan`1 polygon)
   at SixLabors.ImageSharp.Drawing.Shapes.TessellatedMultipolygon.Create(IPath path, MemoryAllocator memoryAllocator)
   at SixLabors.ImageSharp.Drawing.Processing.Processors.Drawing.FillPathProcessor`1.OnFrameApply(ImageFrame`1 source)

Images

N/A - these are SVG path parsing bugs, no image files needed. The crashing inputs are inline SVG path strings in the reproduction code above.

[JimBobSquarePants]

Thanks for the report and for providing repro cases.

The behavior described here does not meet our threshold for a denial of service vulnerability. The examples provided demonstrate that malformed SVG path input can trigger standard runtime exceptions such as IndexOutOfRangeException and ArithmeticException. These are ordinary managed exceptions and do not represent uncontrolled resource consumption, infinite loops, or memory corruption.

ImageSharp.Drawing is a library, not a network-facing service. It operates on caller-provided input and does not impose its own trust boundary. As with any library processing untrusted data, it is the responsibility of the host application to validate input and handle exceptions appropriately. A process crash would only occur if the application allows these exceptions to go unhandled.

That said, the underlying issue is valid from a robustness perspective. The parser should fail more gracefully when encountering malformed path data, and we will address this as a bug fix to improve input validation and error handling.

This will be tracked and resolved as a correctness and hardening issue, not as a security advisory.

[pawlos]

@JimBobSquarePants sure. I've deleted that line from the initial report.