Common Vulnerabilities and Exposures assigned CVE-2014-9670 to the following issue: Multiple integer signedness errors in the pcf_get_encodings function in pcf/pcfread.c in FreeType before 2.5.4 allow remote attackers to cause a denial of service (integer overflow, NULL pointer dereference, and application crash) via a crafted PCF file that specifies negative values for the first column and first row. http://code.google.com/p/google-security-research/issues/detail?id=158 http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=ef1eba75187adfac750f326b563fe543dd5ff4e6
Created freetype tracking bugs for this issue: Affects: fedora-all [bug 1191099]
freetype-2.5.3-15.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
freetype-2.5.0-9.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Upstream bug is: https://savannah.nongnu.org/bugs/?43548 Issue was fixed upstream in 2.5.4. Affected code reads 4 short values from the input file. There are 2 "pairs", for which difference is computed and 1 added to the difference (basically: last - first + 1). Results are multiplied together to produce the number of encodings. Resulting value is in the range of 32bit signed integer (-2^31 to 2^31-1). Negative values cause freetype memory allocation function to return error, which causes pcf_get_encodings() to exit early. The value of 0 causes memory allocation function to return NULL, which is later dereferenced, leading to crash. Positive values are ok. As value of each operand of the multiplication can not exceed 65536 (i.e. 2^16), result can not exceed 2^32. Therefore, this can not lead to allocation of a too small buffer that is later overflown. Hence there is no memory corruption / code execution impact. Note that the integer signedness issue mentioned in the upstream report does not seem relevant. The same would be possible if first* and last* variables were unsigned. Also noted that the NULL pointer dereference occurs in the code introduced by this commit: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=0eb6316f which was added in upstream version 2.4.12. It does not seem to be possible to trigger NULL pointer dereference in earlier versions, hence this does not seem to have any practical impact on the freetype packages in Red Hat Enterprise Linux 7 and earlier.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:0696 https://rhn.redhat.com/errata/RHSA-2015-0696.html