Bug 56566

Summary: Memory leaks in font-related code
Product: cairo Reporter: Kevin Tardif <kiyoka>
Component: pdf backendAssignee: Adrian Johnson <ajohnson>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: major    
Priority: medium    
Version: 1.12.6   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: The patch
The test case
PDF to trigger the leak

Description Kevin Tardif 2012-10-30 04:42:31 UTC
Created attachment 69279 [details]
The patch

I've located two memory leaks in the pdf backend.

In cairo-type1-subset.c, _cairo_type1_font_subset_fini doesn't free font->cleartext (set by cairo_type1_font_subset_decrypt_eexec_segment).

In cairo-cff-subset.c, _cairo_cff_font_create can exit without freeing font->font_name and/or font->data; _cairo_cff_font_load_opentype_cff is called to allocate font_name, then _cairo_cff_font_load_cff is called to allocate font->data, then _cairo_cff_font_load_cff's return status is checked and if it failed, it jumps to fail1. This can cause font_name to leak since the fail1 target only frees the font variable. In addition, _cairo_cff_font_load_cff can fail -after- allocating data, and then data won't be freed either.

I've attached a patch against the latest (5a6e1d) commit in the master repo and a test case with a pdf I found on the web that triggers it.
Comment 1 Kevin Tardif 2012-10-30 04:43:04 UTC
Created attachment 69280 [details]
The test case
Comment 2 Kevin Tardif 2012-10-30 04:43:28 UTC
Created attachment 69281 [details]
PDF to trigger the leak
Comment 3 Adrian Johnson 2012-10-30 10:24:53 UTC
Thanks for the patch and test case.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.