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.
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.
(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
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.
Additional patch (in the harfbuzz git) to protect against possible integer overflow in hb_buffer_ensure: http://cgit.freedesktop.org/harfbuzz/commit/?id=b5dd44e24669
(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.
This is public now via: https://build.opensuse.org/request/show/63070
Created pango tracking bugs for this issue Affects: fedora-all [bug 681378]
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
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.