Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 352087 (CVE-2011-0020) - <x11-libs/pango-1.28.3-r1: Heap corruption when using FreeType2 backend (CVE-2011-0020)
Summary: <x11-libs/pango-1.28.3-r1: Heap corruption when using FreeType2 backend (CVE-...
Alias: CVE-2011-0020
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Whiteboard: A2 [glsa]
Depends on:
Blocks: CVE-2011-0064
  Show dependency tree
Reported: 2011-01-19 04:29 UTC by Tim Sammut (RETIRED)
Modified: 2014-05-17 19:31 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Sammut (RETIRED) gentoo-dev 2011-01-19 04:29:28 UTC
From the upstream bug at URL:

As reported by Dan Rosenberg to Ubuntu in:

When used with FreeType2 as a backend, Pango is vulnerable to heap corruption
when rendering malformed fonts. The vulnerability occurs in
pango_ft2_font_render_box_glyph() in pango/pangoft2-render.c. A buffer is
malloc'd with size box->bitmap.rows * box->bitmap.pitch. Subsequently, 0xff is
written at offsets into this buffer without checking that these offsets fall
within the buffer's boundaries, leading to heap corruption.

I tested this against Lucid (Pango 1.28.0) and upstream (Pango 1.28.3).

I've attached a fuzzed version of the FreeSerif TrueType font ("crash.ttf")
that can be used to reproduce this corruption as follows, using the
test-mixed.txt file included in the pango-view directory of the source tree
(also attached):

# cp /usr/share/fonts/truetype/freefont/FreeSerif.ttf
# cp crash.ttf /usr/share/fonts/truetype/freefont/FreeSerif.ttf
# pango-view --backend=ft2 --font=FreeSerif test-mixed.txt
*** glibc detected *** pango-view: malloc(): memory corruption:
0x000000000116cfa0 ***
======= Backtrace: =========
Comment 1 Tim Sammut (RETIRED) gentoo-dev 2011-01-23 17:20:54 UTC
Per this has been assigned CVE-2011-0020.
Comment 2 Pacho Ramos gentoo-dev 2011-03-12 18:18:26 UTC
+*pango-1.28.3-r1 (12 Mar 2011)
+  12 Mar 2011; Pacho Ramos <> -files/pango-1.2.5-lib64.patch,
+  -pango-1.24.5-r1.ebuild, -files/pango-1.26.0-introspection-automagic.patch,
+  -pango-1.26.2.ebuild, +pango-1.28.3-r1.ebuild,
+  +files/pango-1.28.3-heap-corruption.patch,
+  +files/pango-1.28.3-malloc-failure.patch:
+  Fix security issues: CVE-2011-0020 and CVE-2011-0064. Remove old.
Comment 3 Tim Sammut (RETIRED) gentoo-dev 2011-03-12 18:31:35 UTC
Thanks, Pacho.

Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Comment 4 Alex Buell 2011-03-12 23:15:45 UTC
Tested on SPARc, passed its tests. Could stabilise.
Comment 5 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-03-13 11:00:44 UTC
ppc/ppc64 stable
Comment 6 Agostino Sarubbo gentoo-dev 2011-03-13 13:09:30 UTC
amd64 ok
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2011-03-13 14:29:41 UTC
x86 stable
Comment 8 Tobias Klausmann gentoo-dev 2011-03-13 17:48:52 UTC
Stable on alpha.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2011-03-14 20:49:40 UTC
amd64 done. Thanks Agostino
Comment 10 Jeroen Roovers gentoo-dev 2011-03-15 15:39:57 UTC
Stable for HPPA.
Comment 11 Raúl Porcel (RETIRED) gentoo-dev 2011-03-18 17:33:29 UTC
arm/ia64/s390/sh/sparc stable
Comment 12 Tim Sammut (RETIRED) gentoo-dev 2011-03-19 22:42:50 UTC
Thanks folks. Added existing GLSA request.
Comment 13 GLSAMaker/CVETool Bot gentoo-dev 2011-06-24 00:34:23 UTC
CVE-2011-0020 (
  Heap-based buffer overflow in the pango_ft2_font_render_box_glyph function
  in pango/pangoft2-render.c in libpango in Pango 1.28.3 and earlier, when the
  FreeType2 backend is enabled, allows user-assisted remote attackers to cause
  a denial of service (application crash) or possibly execute arbitrary code
  via a crafted font file, related to the glyph box for an FT_Bitmap object.
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2014-05-17 19:31:44 UTC
This issue was resolved and addressed in
 GLSA 201405-13 at
by GLSA coordinator Sean Amoss (ackle).