Details

[Home]

Issue of the Implementation # S0817

Brief

Segmentation fault in FT_Done_FreeType when using a custom renderer module

Detailed Description

After adding a renderer module via FT_Add_Module for a glyph type other than FT_GLYPH_FORMAT_OUTLINE, calling FT_Done_FreeType results in segmentation fault.

It seems that it happens because 'raster' field of FT_RendererRec_ structure remains uninitialized for such renderers. In fact, there is no way to properly initialize this field using public Freetype API.

If 'raster' is not initialized at least with NULL, it may lead to memory access violation when trying to release the library. FT_Done_Freetype eventually calls ft_remove_renderer(). Consider the following lines of this function (ftobjs.c from git repository, line 3682):

/* release raster object, if any */ 
if ( render->raster ) 
render->clazz->raster_class->raster_done( render->raster ); 

As far as one can see from Freetype reference, 'raster_class' field of FT_Renderer_Class_ structure is intended to use for FT_GLYPH_FORMAT_OUTLINE renderers only. As for the renderers for other formats, 'raster_class' may be set to NULL.

So, as 'render–>raster' is not initialized and may contain some non-NULL garbage, the lines above will result in NULL pointer dereference. Even if 'render–>clazz–>raster_class' is not NULL and provides 'raster_done' method, the latter will be called with an invalid pointer - access violation again.

The definition of FT_RendererRec_ structure is private and hence 'raster' field is not accessible directly (and it probably should not be).

Initialization of 'raster' field via raster_new() is available only for FT_GLYPH_FORMAT_OUTLINE format, so this too cannot be used as a workaround.

Problem location(s) in the standard

Linux Standard Base Desktop Specification 3.2, Chapter 12. Libraries, 12.1 Interfaces for libfreetype that refers FreeType-2.1.10 API Reference, section "Module Management"

Component

freetype 2.3.8 or later

Accepted

Freetype bug tracker, ticket #27648

Status

Fixed in freetype 2.3.13

[Home]