Re: [ft-devel] Outline n_points are int16 so overflow is possible because missing check

[Werner LEMBERG]

> I want to report bug in handling huge (in number of points) glyphs.
> (I can provide such generated font on request, don't sending to list
> as it has 1.2MB)

Thanks for the report.  Please send this font to me.

> If you create Type1 (could apply also to different types) font with
> more than 32767 points in one glyph outline->n_points will wrap
> around 16bits to -32768 in t1_builder_add_point and start corrupting
> memory.  IMHO check for this limitation needs to be added to
> FT_GlyphLoader_CheckPoints function.  But there could be another
> problem with local overflow in:
>
> #define FT_GLYPHLOADER_CHECK_P( _loader, _count )                    \
>    ( (_count) == 0 || (int)((_loader)->base.outline.n_points    +    \
>                             (_loader)->current.outline.n_points +    \
>                             (_count)) <= (int)(_loader)->max_points )
>
> In some cases sum could be also done in shorts then widened to int
> and not detecting overflow, so it will not call
> FT_GlyphLoader_CheckPoints.

I won't going to fix this immediately -- I'm still waiting for
Toshiya-san's 16bit fixes to appear in the git; he has shown them some
time ago on the list but hasn't found time yet to apply.

> Maybe better solution would be completely remove this limitation by
> changing all these shorts to ints and actually increase speed on
> most platforms (unfortunately - this would need to be done on many
> places look at contours array).

IIRC, Toshiya's fixes take care of this problem too.


    Werner