The function atof use the system locale to define the decimal delimiter character (. or ,). The side effect is that the decimales are discarded. For example atof("4.5"); returns 4.0when the locale define , as the delimiter.

One correction could be :

static NSVG_INLINE float nsvg__atof(const char* s)
{
	char o[32] ;
	strcpy(o, setlocale(LC_NUMERIC, NULL)) ;

	setlocale(LC_NUMERIC,"C");
	float f = atof(s);
	setlocale(LC_NUMERIC, o);
	
	return f;
}

path->pts is an array of float reallocated at nanosvg.h:line 694 in nsvg__addPoint path->cpts is a number of allocated pairs, can be 0,8,16,32... Propose path->cpts=8. path->npts is a number of used pairs, increasing 0,1,2... Propose path->npts=7 Condition 'if (p->npts+1 > p->cpts)' { will be false and no new realloc. There is 16 floats allocated. p->npts++ will be 8. Then look into nanosvgrast.h:line 375, for (i = 0; i < path->npts-1; i += 3) { float* p = &path->pts[i*2]; nsvg__flattenCubicBez(r, p[0]*scale,p[1]*scale, p[2]*scale,p[3]*scale, p[4]*scale,p[5]*scale, p[6]*scale,p[7]*scale, 0, 0); } Last i==6 will be addressed to [6*2+7] which is out of bound. What I missed?

Mid-June, I discovered and privately reported an endless loop issue that happens in the following usage scenario with a small crafted input file:

#include <stdint.h>
#include <stdio.h>

#define NANOSVG_IMPLEMENTATION
#include "nanosvg.h"

int main(int argc, char *argv[]) {
  // this will loop for some inputs
  NSVGimage* g_image = nsvgParseFromFile("nanosvg_loop_examplefile1.svg", "px", 96);
  return 0;
}

The expected security impact is a denial of service.

So far, I have not received a reply from @memononen. Given that nanosvg is not actively maintained (see README.md), this is somewhat expected, but I want to report the issue anyway because there might still be active users of this library that are affected by this.

@memononen : can you give some quick feedback on whether you want the details to be disclosed publicly here in the bugtracker or prefer them to stay nonpublic until the 15.9.2020 (90 days after initial disclosure)?

This simple Proof of Concept

<stop style="stop-color:rgb(0%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%)"/>

crashes nanosvg. In this snippet it is clear why this happens:

#include <stdio.h>
#include <string.h>

static unsigned int nsvg__parseColorRGB(const char* str)
{
	int r = -1, g = -1, b = -1;
	char s1[32]="", s2[32]="";
	sscanf(str + 4, "%d%[%%, \t]%d%[%%, \t]%d", &r, s1, &g, s2, &b);
	if (strchr(s1, '%')) {
		return 1;
	} else {
		return 0;
	}
}

int main(int argc, char const *argv[])
{
	printf("%d\n", nsvg__parseColorRGB("rgb(0%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%)"));
	return 0;
}

sscanf tries to parse the string, and writes arbitrary number of '%' or '\t' into the s1 or s2 buffer. The buffer overflows and triggers a segfault. This could lead to memory corruption and/or denial of service.

Regards bitwave

CC: @gehaxelt for the fuzzing

When attempting to render the firefox logo using the example2.c file from this repository I get the following output:

This is the SVG:

I first noticed this problem when using Fuzzel (this launcher uses nanosvg for rendering SVGs).

Please let me know if you need more information, thanks in advance.

Currently, the NanoSVG parser and rasterizer don't handle clip-paths at all (and won't even ignore them). This PR adds some support for them (via stencil bit buffers, including support for multiple intersecting clip paths).

Here's a demo file exported from Affinity Designer using folded clip paths:

clip-path-ball.zip

With the current master NanoSVG, this is generated:

With the PR, the image is rendered correctly:

Hello! I am trying to use your library to parse .svg files, and then use libtess2 for tesselation in a game engine.

When I get an .svg file from the web, it works just fine. When I save it from Illustrator 2017, it does not (most times). Have they updated the format or something?

Looking at the xml, it might seem that version 1.0 is working and 1.1 is not, but I am just guessing randomly at this point.

Any suggestions :) ?

Library doesn't render proper colors. For example pure white #FFFFFF is rendered as #FCFCFC, you can check whites on tiger from library description. #000000 is rendered as #010101. Gradients seems to be affected to. Do you have any idea what could be source of this problem?

Edit: Maybe this? (an other >> 8 operations) int a = ((int)cover[0] * ca) >> 8; vs int a = ((int)cover[0] * ca) / 255;

Hi,

Try the following path and you will get a parse error due to a division by 0 in nsvg__pathArcTo()

<?xml version="1.0" encoding="utf-8"?><svg version="1.1" id="Layer_1" width="10000mm" height="10000mm"><path d="M40.7595, -20.5388 A38.200000000000074,38.200000000000074,0,0,1,32.0609, -22.2933"/></svg>

The included patch fixes the bug and does not seem to create regression, as observed by the folowing screen shots

patch:

Index: trunk/src/nanosvg.h
===================================================================
--- trunk/src/nanosvg.h (revision 50)
+++ trunk/src/nanosvg.h (working copy)
@@ -1887,7 +1887,7 @@
    t[4] = cx; t[5] = cy;

    // Split arc into max 90 degree segments.
-   ndivs = (int)(fabsf(da) / (NSVG_PI*0.5f) + 0.5f);
+   ndivs = (int)(fabsf(da) / (NSVG_PI*0.5f) + 1.0f);
    hda = (da / (float)ndivs) / 2.0f;
    kappa = fabsf(4.0f / 3.0f * (1.0f - cosf(hda)) / sinf(hda));
    if (da < 0.0f)

it seems rasterization is broken on my builds. any idea?

here is the relevant code:

// Load SVG, parse and rasterize
char *str = new char[ size + 1 ];
memcpy( str, ptr, size );
str[size] = '\0';

NSVGimage *image = nsvgParse( str, "px" /*units*/, 96.f /* dpi */ );
if( image ) {
    // Create rasterizer (can be used to render multiple images).
    static struct install {
        NSVGrasterizer *rasterizer;
         install() { rasterizer = nsvgCreateRasterizer(); }
        ~install() { if( rasterizer ) nsvgDeleteRasterizer( rasterizer ); rasterizer = 0; }
    } local;
    // Allocate memory for image
    int w = image->width;
    int h = image->height;

    double scale = 1.0;
    imageWidth = image->width * scale;
    imageHeight = image->height * scale;
    imageBpp = 4;

    imageuc = (stbi_uc *)malloc(w*h*4);
    deleter = FREE_DELETER;
    if( imageuc ) {
        // Rasterizes SVG image, returns RGBA image (non-premultiplied alpha)
        //   r - pointer to rasterizer context
        //   image - pointer to image to rasterize
        //   tx,ty - image offset (applied after scaling)
        //   scale - image scale
        //   dst - pointer to destination image data, 4 bytes per pixel (RGBA)
        //   w - width of the image to render
        //   h - height of the image to render
        //   stride - number of bytes per scaleline in the destination buffer
        nsvgRasterize( local.rasterizer, image, 0,0,scale, imageuc, w, h, w*scale*4 );
    }
    nsvgDelete(image);
}

delete [] str;

ps: thanks for the lib btw! :grin:

Hi,

Hi I use Arch Linux and standard package for fuzzel from official repository doesn't ship with librsvg and only nanosvg. As result I doesn't see many icons from beautyline icon set.

Official fuzzel Arch package:

And fuzzel build from git with librsvg:

Is there a chance that nanosvg would work with beautyline?

nanosvg.h does not appear to currently support HTML entity codes, such as &#59; for ". This is troublesome because some special characters like "<> can only appear in some positions as entities. A tool I am using ("Figma") is encoding a > characters in a shape id as &#62;, which is causing problems for my program when it tires to read that id using nanosvg (and it sees a raw &#62; instead of the < it expects).

I wrote a small &# code decoder and would like to upstream it as a PR. However, I'm not sure exactly where to put it. I think the place to put the entity decode is

	} else if (strcmp(name, "id") == 0) {
		strncpy(attr->id, value, 63);

in nsvg__parseAttr, either right after the strncpy or possibly replacing it. However, are there other places it is appropriate to do HTML entity decoding in such a patch? For example are <text> tags currently supported?

If a shape's "fill" property is an url(), then attr->hasFill gets set to 2, but then at this point NanoSVG when checking for hasFill 2 checks to see if there's a gradient and if there's no gradient it just sets the shape fill type to NSVG_PAINT_NONE. This is causing my app to misbehave because it handles PAINT_NONE in a particular way and even if it can't currently access the fill url() through nanoSVG currently, it's important to know it is filled.

I have locally patched this with:

diff --git a/src/nanosvg.h b/src/nanosvg.h
index 79a9878..0c55b8b 100644
--- a/src/nanosvg.h
+++ b/src/nanosvg.h
@@ -75,7 +75,8 @@ enum NSVGpaintType {
        NSVG_PAINT_NONE = 0,
        NSVG_PAINT_COLOR = 1,
        NSVG_PAINT_LINEAR_GRADIENT = 2,
-       NSVG_PAINT_RADIAL_GRADIENT = 3
+       NSVG_PAINT_RADIAL_GRADIENT = 3,
+       NSVG_PAINT_SPECIAL = 4
 };

 enum NSVGspreadType {
@@ -995,7 +996,7 @@ static void nsvg__addShape(NSVGparser* p)
                nsvg__getLocalBounds(localBounds, shape, inv);
                shape->fill.gradient = nsvg__createGradient(p, attr->fillGradient, localBounds, &shape->fill.type);
                if (shape->fill.gradient == NULL) {
-                       shape->fill.type = NSVG_PAINT_NONE;
+                       shape->fill.type = NSVG_PAINT_SPECIAL;
                }
        }

I could create a PR, but I don't know if this is how you want it done upstream because nanosvgrast won't know how to deal with the new NSVG_PAINT_SPECIAL type.

Say I have this basic SVG file:

<svg width="356px" height="335px" viewBox="0px 0px 356px 335px" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect width="356px" height="335px" fill="white"/>
<rect x="40px" y="70px" width="53px" height="58px" fill="#D9D9D9"/>
</svg>

...and I open it by calling nsvgParse(svgString, "px", 0.25);. Nanosvg converts the units of the numbers in the files to pixels (a null conversion) and then divides them by four. Everything is as I expect when I read back the numbers.

However say I then try to load this other file, which is the same but instead of "px" all values are unitless:

<svg width="356" height="335" viewBox="0 0 356 335" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect width="356" height="335" fill="white"/>
<rect x="40" y="70" width="53" height="58" fill="#D9D9D9"/>
</svg>

The art program I am currently using emits SVGs with this format. In this case, opening with nsvgParse(svgString, "px", 0.25); does not produce any rescaling. The DPI value appears to get totally ignored.

Is this intentional?

Expected behavior:

1. I find many sources online suggesting that if units are not provided on a value in an SVG file, the units are to be taken as px. Looking at section 8 of the SVG spec I am a little confused as to whether this is true, but spec section 8.3 seems to say this is the case for at least the viewport (IE, the width and height of the file itself):

   If the width or height presentation attributes on the outermost svg element are in user units (i.e., no unit identifier has been provided), then the value is assumed to be equivalent to the same number of "px" units (see Units).

   So I would expect a SVG file with no units to behave exactly the same as the px units.

2. If the behavior is intentional, and DPI does not control the scaling of user units, then I would hope for some way to manually invoke scaling in place of using DPI, as scaling a document as it is loaded is useful.

3. Finally, whichever way nanoSvg behaves, I think the comment in the header file explaining DPI should be a little clearer. Currently all it says is:

   // The units passed to NanoSVG should be one of: 'px', 'pt', 'pc' 'mm', 'cm', or 'in'. // DPI (dots-per-inch) controls how the unit conversion is done.

   This description does not mention user units (unitless values) as an option, and the description of what the DPI value means is vague. What does DPI mean when the value is of type "cm", or "px"?

Analysis:

I tried running NanoSVG in a debugger and breaking on nsvg__convertToPixels. What I found is that with the "unitless" sample file the switch statement was always NSVG_UNITS_USER (expected). However when I tested with the sample file where every value is px, the switch statement went to NSVG_UNITS_CM (very surprising). In the code, DPI is applied to values of type pt, pc, mm, cm, in but is not applied to values of type user-unit or pixel.

In other words, from reading the code, the original intention of the code appears to be that the DPI should be ignored in both of my two sample files above; I assumed the bug was in the unitless case, but maybe it is the px case that has the bug. I do not understand where nanosvg is getting cm from because it is not either in the file nor the unit given to my nsvgParse() call.

Configuration

I am using nanosvg from the github repo, version 3bcdf2f3cdc

error svg sample:

    <linearGradient id="Gradient-3" x1="-58.064" y1="-3.352" x2="49.041" y2="-3.352" >
        <stop offset="0" stop-color="#f0a532"/>
        <stop offset="0.5" stop-color="#f8b645"/>
        <stop offset="1" stop-color="#ffc758"/>
    </linearGradient>


</defs>



        <g id="Comp-3" transform="translate(190,190)">
            <g id="Group-1-3" opacity="1">
                <path id="Path-1-3" fill="none" d="M49.302,-49.302C-5.156,-49.302,-49.302,-5.156,-49.302,49.302" stroke="url(#Gradient-3)" stroke-opacity="1" stroke-width="17" stroke-miterlimit="10"  stroke-dasharray="70" stroke-dashoffset="70.001" />
            </g>
        </g>