Bug 678563 - (CVE-2011-0064) CVE-2011-0064 pango: missing memory reallocation failure checking in hb_buffer_ensure
CVE-2011-0064 pango: missing memory reallocation failure checking in hb_buffe...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Red Hat Product Security
public=20110301,reported=20110215,sou...
: Security
Depends On: 679693 679694 681378
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-18 07:43 EST by Jan Lieskovsky
Modified: 2015-11-24 09:36 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-30 14:50:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch ported to pango (6.14 KB, patch)
2011-02-23 04:18 EST, Tomas Hoger
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2011-02-18 07:43:08 EST
It was discovered that pango did not check for memory reallocation failures in hb_buffer_ensure() function.  This could trigger a NULL pointer dereference in hb_buffer_add_glyph(), where possibly untrusted input is used as an index used for accessing members of the incorrectly reallocated array, resulting in the use of NULL address as the base array address.  This can result in application crash or, possibly, code execution.

It was demonstrated that it's possible to trigger this flaw in Firefox via a specially crafted web page.

Mozilla bug report (currently not public):
https://bugzilla.mozilla.org/show_bug.cgi?id=606997

Fix in the harfbuzz git:
http://cgit.freedesktop.org/harfbuzz/commit/?id=a6a79df5fe2e

Acknowledgements:

Red Hat would like to thank Mozilla Security Team for reporting this issue.
Comment 1 Jan Lieskovsky 2011-02-18 08:07:47 EST
This issue affects the versions of the pango package, as shipped with
Red Hat Enterprise Linux 3, 4, 5, and 6.

This issue affects the versions of the evolution28-pango package, as
shipped with Red Hat Enterprise Linux 4.

--

This issue affects the versions of the pango package, as shipped with
Fedora release of 13 and 14.
Comment 7 Tomas Hoger 2011-02-23 03:57:47 EST
(In reply to comment #1)
> This issue affects the versions of the pango package, as shipped with
> Red Hat Enterprise Linux 3, 4, 5, and 6.
> 
> This issue affects the versions of the evolution28-pango package, as
> shipped with Red Hat Enterprise Linux 4.

This initial assessment was incorrect.  The issue only affects pango version in Red Hat Enterprise Linux 6.  Upstream dropped realloc failure checking code in this commit:
  http://git.gnome.org/browse/pango/commit/?id=336bb320
Comment 9 Tomas Hoger 2011-02-23 04:18:29 EST
Created attachment 480386 [details]
Patch ported to pango

(In reply to comment #0)
> Upstream patch:
> [2] http://cgit.freedesktop.org/harfbuzz/commit/?id=a6a79df5fe2e

Port of this harfbuzz patch to pango, by Karl Tomlinson.
Comment 10 Tomas Hoger 2011-02-28 14:38:05 EST
Additional patch (in the harfbuzz git) to protect against possible integer overflow in hb_buffer_ensure:
  http://cgit.freedesktop.org/harfbuzz/commit/?id=b5dd44e24669
Comment 11 Tomas Hoger 2011-03-01 05:10:56 EST
(In reply to comment #10)
> Additional patch (in the harfbuzz git) to protect against possible integer
> overflow in hb_buffer_ensure:
>   http://cgit.freedesktop.org/harfbuzz/commit/?id=b5dd44e24669

Further review of the pango code confirmed that the overflow is not possible in the current versions.

In most hb_buffer_ensure calls, the requested buffer size is only 1 larger than the current number of items in the buffer (and hence at most current capacity + 1).  _hb_buffer_add_output_glyphs is the only place that may request extension larger than 1 (num_out argument).  Sequence::apply is the only place that may call that function with num_out greater than 1.  It passes substitute.len value as num_out argument, which is of unsigned short type and hence 0xffff at max.

Due to that, the loop adjusting new_allocated will not run more than once when current buffer size is large enough to possibly trigger realloc overflow after the new_allocated value increase.  On 32bit platforms, that would require current buffer size of at least 0x8888884 items, which means total memory allocation that already exceeds 2^32 memory size limit and hence is impossible.

The overflow can never happen on 64bit platforms (new_allocated * sizeof(...) is evaluated as size_t expression).

Thanks to Karl Tomlinson for the review and feedback.
Comment 12 Vincent Danen 2011-03-01 18:34:12 EST
This is public now via:

https://build.opensuse.org/request/show/63070
Comment 13 Vincent Danen 2011-03-01 18:35:14 EST
Created pango tracking bugs for this issue

Affects: fedora-all [bug 681378]
Comment 14 errata-xmlrpc 2011-03-01 18:43:43 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0309 https://rhn.redhat.com/errata/RHSA-2011-0309.html
Comment 15 Huzaifa S. Sidhpurwala 2011-09-09 03:33:05 EDT
In all the versions of qt shipped with RHEL, in the embedded harfbuzz code,
hb_buffer_ensure / otl_buffer_ensure returned an error and hb_buffer_add_glyph
/ otl_buffer_add_glyph had a check for the error.

Hence it was not vulnerable to the realloc failure.

Statement:

This issue did not affect the versions of qt shipped with Red Hat Enterprise Linux 4, 5 and 6.

Note You need to log in before you can comment on or make changes to this bug.