bugThe FreeType Project - Bugs: bug #46439, Leak of glyph_name after being...


You are not allowed to post comments on this tracker with your current authentication level.

bug #46439: Leak of glyph_name after being allocated in bdf parser.

Submitter:  bungeman <bungeman>
Submitted:  Fri 13 Nov 2015 09:19:17 PM UTC
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.6.2

Mon 16 Nov 2015 03:37:06 PM UTC, comment #2: 

> Maybe your patch to ftfuzzer could be incorporated if controlled by, say, an environment variable or a command line option?

That would probably be a good idea, though I'm not sure what to call such an option nor exactly what it should look like. The issue is that this does two separate things. The first is to ensure there is nothing shared between runs (tying the FT_Library to the stack frame). The second if to force lsan to run each time. Something like 'FT_FUZZER_FULL_ISOLATION' or something might work.

If this were a runtime flag it may be required to dynamically load the lsan symbols (instead of assuming that the user is always running with an lsan build). If this is a compile time flag it might need to be two flags, one for forcing the FT_Library to the stack frame and another for forcing lsan to run each time.

bungeman <bungeman>
Sun 15 Nov 2015 03:54:29 AM UTC, comment #1: 

Fixed in git, thanks!

Maybe your patch to ftfuzzer could be incorporated if controlled by, say, an environment variable or a command line option?

Werner LEMBERG <wl>
Group administrator
Fri 13 Nov 2015 09:19:17 PM UTC, original submission:  

Found with libFuzzer at FreeType 75722f89290eb1cb316cd240763545d7277e0481 , reproduction attached.

An example sort of report for this issue from LeakSanitizer is:

ERROR: LeakSanitizer: detected memory leaks

Direct leak of 30 byte(s) in 5 object(s) allocated from:

__interceptor_malloc llvm_all/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
ft_mem_qalloc freetype2/src/base/ftutil.c:76:15
ft_mem_alloc freetype2/src/base/ftutil.c:55:0
ft_mem_qrealloc freetype2/src/base/ftutil.c:146:0
ft_mem_realloc freetype2/src/base/ftutil.c:102:13
_bdf_parse_glyphs freetype2/src/bdf/bdflib.c:1680:12
_bdf_readstream freetype2/src/bdf/bdflib.c:790:17
bdf_load_font freetype2/src/bdf/bdflib.c:2472:0
BDF_Face_Init freetype2/src/bdf/bdfdrivr.c:364:0
open_face freetype2/src/base/ftobjs.c:1178:15
FT_Open_Face freetype2/src/base/ftobjs.c:2176:19
FT_New_Memory_Face freetype2/src/base/ftobjs.c:1268:12
LLVMFuzzerTestOneInput freetype2/src/tools/ftfuzzer/ftfuzzer.cc:199:10
FTFuzzer::TargetFunction(unsigned char const*, unsigned long) freetype2/src/tools/ftfuzzer/ftmutator.cc:153:14

Initially this was reported at the end of a fuzzer run, so I ran all of the produced test cases individually, but this did not reproduce (this appears to occur inside already covered code). I then changed ftfuzzer.cc to force lsan to check after each run, which caused runs of the fuzzer to produce crash files of the cases when this is detected. However, these do not by themselves reproduce either. I then applied the attached ftfuzzer.cc.patch to both force lsan checks on each run and also create a new FT_Library each run (both of which I don't recommend generally, it makes things much slower). This causes runs of the fuzzer to produce crash files of the cases when this is detected. This finally produced a reproduction. I'm attaching this ftfuzzer.cc.patch as a local aid in finding actual leak reproductions of this sort, but I do not recommend it for general use.

bungeman <bungeman>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #35450:  ftfuzzer.cc.patch added by bungeman (3KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by bungeman (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-15 wl StatusNone Fixed
        Assigned toNone wl
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.6.2
    2015-11-13 bungeman Attached File- Added ftfuzzer.cc.patch, #35450
        Attached File- Added crash-b4f5bea86648179bf1759ec1b5a3c5c3ec874463, #35451

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code