See how freetype compares to other vendors in security performance
An out-of-bounds read vulnerability exists in FreeType 2.14.3 and versions before commit 5a280ecde6f324de0d226261036e736e0cb49a71 in src/truetype/ttgxvar.c, in the TTGetVarDesign implementation used by FTGetVarDesignCoordinates
Project Zero today made four bugs in FreeType publicly visible.
Fixes appears to have been committed to FreeType's git repo, but no new release made yet, and no CVE id's are listed in the bug reports or commits.
Each individual bug report, on either the Project Zero tracker or the FreeType gitlab, has more details, including technical analysis, reproducers, and suggested fixes from the researchers.
------------------------------------------------------------------------------
FreeType: Heap Buffer Overflow via Improper Limit Calculation in TrueType SHZ Instruction https://project-zero.issues.chromium.org/issues/505355061
Vulnerability Type: Heap Buffer Overflow (Read/Write) Affected Component: TrueType Bytecode Interpreter (ttinterp.c) Affected Versions: Confirmed on v2.14.3 and git head (f2b3f969) Credit: Mateusz Jurczyk of Google Project Zero
A heap buffer overflow vulnerability exists in the FreeType library's TrueType bytecode interpreter. The vulnerability is triggered by the SHZ (Shift Zone) instruction when executed within a composite glyph context. Improper calculation of the loop limit leads to an out-of-bounds memory access (both read and write) in the MoveZp2Point function. An attacker can leverage this to cause an application crash or potentially achieve arbitrary code execution.
Reported at: https://gitlab.freedesktop.org/freetype/freetype/-/workitems/1420 Fixed by https://gitlab.freedesktop.org/freetype/freetype/-/commit/1803559c4ee407d0bcbf2a67dbe96690cee869d2 and several follow-up commits.
------------------------------------------------------------------------------
FreeType: Integer Overflow leading to Out-of-Bounds Read in TrueType IUP Instruction https://project-zero.issues.chromium.org/issues/505357209
Vulnerability Type: Integer Overflow / Out-of-Bounds Read / Denial of Service Affected Component: TrueType Bytecode Interpreter (ttinterp.c) Affected Versions: Confirmed on v2.14.3 and git head (f2b3f969) Credit: Mateusz Jurczyk of Google Project Zero
An integer overflow vulnerability exists in the FreeType library's TrueType bytecode interpreter's handling of the IUP (Interpolate Untouched Points) instruction. By using a signed 16-bit integer for a loop counter that iterates over glyph contours, the interpreter can be forced into an infinite loop or an out-of-bounds read if a glyph contains more than 32,767 contours. This leads to a Denial of Service (DoS) and potential information leakage.
Reported at: https://gitlab.freedesktop.org/freetype/freetype/-/workitems/1421 Fixed in https://gitlab.freedesktop.org/freetype/freetype/-/commit/7974be74d8b5a2fbf99aa88f0461d1f80af51cee.
------------------------------------------------------------------------------
FreeType: Heap Buffer Overflow via Signedness Mismatch in TrueType Variation Handling (ttinterpolatedeltas) https://project-zero.issues.chromium.org/issues/506902245
Vulnerability Type: Heap Buffer Overflow / Integer Wrap-around Affected Component: TrueType Variation Handling (ttgxvar.c) Affected Versions: Confirmed on v2.14.3 and git head (5d109934) Credit: Mateusz Jurczyk of Google Project Zero
A heap-based buffer overflow vulnerability exists in FreeType 2.14.3 when processing composite glyphs in variable fonts. The flaw is caused by a signed 16-bit integer wrap-around in a loop counter within the variation delta interpolation logic. An attacker can leverage this by providing a font with a composite glyph containing more than 32,767 components, leading to out-of-bounds memory access. This vulnerability can potentially result in arbitrary code execution in applications that use FreeType to process untrusted font files.
Reported in https://gitlab.freedesktop.org/freetype/freetype/-/workitems/1423. Fixed in https://gitlab.freedesktop.org/freetype/freetype/-/commit/0d45c7f1911bc6db0bf072eea0c8cdccd77bc6b3.
------------------------------------------------------------------------------
FreeType: Heap Buffer Over-read in ttfacecolrblendlayer via Sub-byte Bitmaps
Vulnerability Type: Heap Buffer Over-read / Information Disclosure Affected Component: COLR v0 Blending (ttcolr.c) Affected Versions: Confirmed on v2.14.3 and git head (5d109934) Credit: Mateusz Jurczyk of Google Project Zero
A heap-based buffer over-read vulnerability exists in FreeType 2.14.3's COLR v0 layer blending function ttfacecolrblendlayer. When a COLR v0 base glyph references a layer glyph backed by an embedded bitmap with a sub-byte pixel mode (1bpp MONO, 2bpp GRAY2, or 4bpp GRAY4), the blending loop incorrectly treats the source bitmap as 8-bit grayscale. This causes the function to read beyond the end of the heap-allocated packed bitmap buffer. The over-read data is directly encoded into the output pixel values, allowing for potential information disclosure of heap memory bytes in applications that process untrusted font files.
Reported in https://gitlab.freedesktop.org/freetype/freetype/-/workitems/1425 Fixed in https://gitlab.freedesktop.org/freetype/freetype/-/commit/cbe12767ea73d1006edc75fcd61c0b0d2a88f34e.
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Hello oss-security,
This is an information-only post documenting a downstream impact and maintainer response for an existing, already-public CVE.
== CVE == CVE-2025-27363 -- FreeType <= 2.13.2 heap-buffer-overflow in loadtruetypeglyph(), src/truetype/ttgload.c (~line 1929). NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-27363 Fix: FreeType 2.13.3, upstream commit a1e5a9df.
== Downstream impact: FontForge == FontForge (https://github.com/fontforge/fontforge) links FreeType to parse and process font files. When built or run against FreeType <= 2.13.2, FontForge inherits the heap-buffer-overflow when opening a maliciously crafted TrueType font.
We confirmed the issue with AddressSanitizer against FreeType 2.13.0 (common in distributions that have not backported the fix):
==ERROR: AddressSanitizer: heap-buffer-overflow WRITE of size 16 at ttgload.c:1929 in loadtruetypeglyph 0 bytes to the right of 16-byte region allocated at ttgload.c:1909
Recommended action for distributors and packagers: ensure FontForge is built/linked against FreeType >= 2.13.3, or apply the upstream fix (commit a1e5a9df).
== Upstream maintainer response == We reported this downstream impact to FontForge upstream as https://github.com/fontforge/fontforge/issues/5799 (2026-04-15). The issue was closed within hours under "Community-guidelines #D1", which states that the project does not accept security reports without an accompanying fix PR.
Context: ZDI submitted 12 unrelated FontForge CVEs in 2025-12 and received the same response (https://github.com/fontforge/fontforge/issues/5706).
We post here so distributors and downstream packagers have a public, independent record of the FontForge -> FreeType linkage status, and can verify their own builds.
== Reproducer == Public PoC: https://github.com/francozappa/poc-CVE-2025-27363 Build/run FontForge against FreeType 2.13.0 or 2.13.2 with the PoC TTF to reproduce.
Regards, vulgraph (Academic security research; PhD work on 1-day vulnerability propagation across forks and downstream consumers.)
While the announcement below says "A bunch of potential security problems have been found. All users should update." the Meta CNA has issued CVE-2026-23865, stating: An integer overflow in the ttvarloaditemvariationstore function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
Affected Version Information:
FreeType (FreeType) Default Status: affected affected from 2.13.2 through 2.13.3 affected from 2.14.0 through 2.14.1
References:
https://gitlab.com/freetype/freetype/-/commit/fc85a255849229c024c8e65f536fe1875d84841c https://sourceforge.net/projects/freetype/files/freetype2/2.14.2/ -------- Forwarded Message -------- Subject: Announcing FreeType 2.14.2 Date: Sun, 1 Mar 2026 20:46:54 +0000 From: Werner LEMBERG <wl () gnu org> To: freetype-announce () nongnu org, freetype () nongnu org, freetype-devel () nongnu org
FreeType 2.14.2 has been released.
It is available from
https://savannah.nongnu.org/download/freetype/
or
https://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjoy!
Werner
PS: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use https://download-mirror.savannah.gnu.org/releases/
----------------------------------------------------------------------
https://www.freetype.org
FreeType 2 is a software font engine that is designed to be small, efficient, highly customizable, and portable while capable of producing high-quality output (glyph images) of most vector and bitmap font formats.
Note that FreeType 2 is a font service and doesn't provide APIs to perform higher-level features, like text layout or graphics processing (e.g., colored text rendering, 'hollowing', etc.). However, it greatly simplifies these tasks by providing a simple, easy to use, and uniform interface to access the content of font files.
FreeType 2 is released under two open-source licenses: our own BSD-like FreeType License and the GPL. It can thus be used by any kind of projects, be they proprietary or not.
----------------------------------------------------------------------
You can use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding archive. Then, run a command like this:
gpg --verify freetype-2.14.2.tar.gz.sig
If that command fails because you don't have the required public key, execute
gpg --keyserver pgp.mit.edu --recv-keys BE6C3AAC63AD8E3F
to import it, then rerun the gpg --verify command.
SHA1 file checksums:
ad090dafb29135d08665eba400a1b1b66edd7313 freetype-2.14.2.tar.gz 28200b8f8df5a524f476bdacb20f05da1c33280c freetype-2.14.2.tar.xz cde32902a8bffed4c855570bc86a2584fa373ff8 ft2142.zip dac409e7009221f14b9367d4581d54a895bfe624 ft2demos-2.14.2.tar.gz cccaa9ec2e4327901fafd6e830885dc9131d9c2d ft2demos-2.14.2.tar.xz c04d9c5ef4d929185c01d5f63162a4656578fd14 ftdmo2142.zipA bunch of potential security problems have been found. All users should update. aca81e3c7bb5793b957c2d4ff61e58ad726b00a5 freetype-doc-2.14.2.tar.gz adf5448cb668073545ba87b23cff21a08b56d3de freetype-doc-2.14.2.tar.xz 4eeadfe25683500562a31f38920a24867e178f52 ftdoc2142.zip
SHA256 file checksums:
752c2671f85c54a84b7f0dd2b5cd26b6b741117033886ffbc5ac89a68464b848 freetype-2.14.2.tar.gz 4b62dcab4c920a1a860369933221814362e699e26f55792516d671e6ff55b5e1 freetype-2.14.2.tar.xz ad3aed6fa521148de639aceb6ac7db25554c68ee122f086232dd33a327175eb1 ft2142.zip fd63fabb75302b71a33f97dbf14e658309985569ed0eaac6355dd8862db65ff2 ft2demos-2.14.2.tar.gz ae9ed4b095e73a3fbdb90363c138ea62ac4b0f55aa4bb345b9b2458783f9284f ft2demos-2.14.2.tar.xz 94f7ecdd05720bde3f15feae9bbf1e885640e97c06efc75c4badaaa6691a0b06 ftdmo2142.zip 5bf511f318256991d3fbe056f0a3fdb191c601c93f079edc7a4ee746e91ec1de freetype-doc-2.14.2.tar.gz 0514edfd6a7b480f753aa48789d7112038a218b0b06afdca320c4bcbc2f66e6b freetype-doc-2.14.2.tar.xz d43d0ce570c8204299d35982b8eb66660d9bb945dbfbd1a00194f30c1225301d ftdoc2142.zip
CHANGES BETWEEN 2.14.1 and 2.14.2 (2026-Mar-01)
I. IMPORTANT CHANGES
- Several changes related to LCD filtering are implemented to achieve better performance and encourage sound practices.
. Instead of blanket LCD filtering over the entire bitmap, it is now applied only to non-zero spans using direct rendering. This speeds up the ClearType-like rendering by more than 40% at sizes above 32 ppem.
. Setting the filter weights with FTFaceProperties is no longer supported. The default and light filters are optimized to work with any face.
. The legacy libXft LCD filter algorithm is no longer provided.
II. IMPORTANT BUG FIXES
- A bunch of potential security problems have been found. All users should update.
- The italic angle in PSFontInfo is now stored as a fixed-point value in degrees for all Type 1 fonts and their derivatives, consistent with CFF fonts and common practices. The broken underline position and thickness values are fixed for CFF fonts.
III. MISCELLANEOUS
- The x field in the FTSpan structure is now unsigned.
- Demo program ftgrid got an option -m to select a start character to display.
- Similarly, demo program ftmulti got an option -m to select a text string for rendering.
- Option -d in the demo program ttdebug is now called -a, expecting a comma-separated list of axis values. The user interface is also slightly improved.
- The ftinspect demo program can now be compiled with Qt6, too.
An integer overflow in the ttvarloaditemvariationstore function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
An integer overflow in the ttvarloaditemvariationstore function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
CISA added this vulnerability to their Known Exploited Vulnerabilities Catalog today, so there will be even more users checking to see if they have it fixed now:
https://www.cisa.gov/news-events/alerts/2025/05/06/cisa-adds-one-known-exploited-vulnerability-catalog
Hopefully the distros all have patches out already.
-alan-
On 3/12/25 16:10, Douglas Bagnall wrote: I don't know much about this bug, which seems to have been announced by Facebook yesterday.
https://nvd.nist.gov/vuln/detail/CVE-2025-27363 An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild. The latest version of FreeType is 2.13.3 which is NOT affected, according to the announcement. Recent distro versions (e.g. Ubuntu 24.04 with 2.13.2) also look safe.
However, older distro versions seem to have affected libraries. For example Debian Bookworm has "2.12.1+dfsg-5+deb12u3", which is less than "2.13.0".
The bug would not be too concerning if people only used trusted fonts, as used to be routine. But webpages now embed fonts, and the affected "variable font files" format is widely used in browsers. It allows parametric adjustment of font properties, described here:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSSfonts/Variablefontsguide
However, it looks like the browsers themselves might be embedding unaffected recent versions of FreeType. For example, I see Mozilla have a commit with the message: Bug 1912903 - Update freetype2 to 2.13.3. https://github.com/mozilla/gecko-dev/commit/026f6a947085020cd189dd9af3da00be433a44f8
I know there's some tension between bundling and unbundling tendencies in the packaging of browsers, so I am not sure how exposed anyone is.
Anyway, I don't see patches for 2.11.x and 2.12.x in stable/LTS releases, and the FreeType website seems pretty quiet about this.
Douglas -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
On Fri, Mar 14, 2025, at 7:55 AM, Marc Deslauriers wrote: Hi Michel,
On 2025-03-13 22:54, Michel Lind wrote: The fixes I'm working with both the Meta security folks and the EL community (CentOS / AlmaLinux) can be tracked herehttps://gitlab.com/redhat/centos-stream/rpms/freetype/-/mergerequests/8/diffs I think if you're removing the 4 "phantom points" from outline.npoint and outline.ncontours, you probably need to add them back in other places, like the parts you are missing from this patch does:
https://gitlab.freedesktop.org/freetype/freetype/-/commit/47103b2f195e0f9664c9470182f063cb7d41dc9f That's a good call. I've been slightly concerned about those 4 points too. Will probably have to cut another fix Is there a reproducer available for this CVE? I was thinking of just doing a minimal fix for older freetype versions in Ubuntu, maybe something like this:
-- a/src/truetype/ttgload.c +++ b/src/truetype/ttgload.c @@ -1957,6 +1957,13 @@
limit = (short)gloader->current.numsubglyphs;
+ / make sure this isn't negative as we're going to add 4 later / + if ( limit < 0 ) + { + error = FTTHROW( InvalidArgument ); + goto Exit; + } + / construct an outline structure for / / communication with TTVaryApplyGlyphDeltas' / outline.npoints = (short)( gloader->current.numsubglyphs + 4 ); I'll ask the security folks to weigh in again
Thanks,
-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://michel-slm.name/
Hi Michel,
On 2025-03-13 22:54, Michel Lind wrote: The fixes I'm working with both the Meta security folks and the EL community (CentOS / AlmaLinux) can be tracked herehttps://gitlab.com/redhat/centos-stream/rpms/freetype/-/mergerequests/8/diffs
https://gitlab.freedesktop.org/freetype/freetype/-/commit/47103b2f195e0f9664c9470182f063cb7d41dc9f -- a/src/truetype/ttgload.c +++ b/src/truetype/ttgload.c @@ -1957,6 +1957,13 @@
limit = (short)gloader->current.numsubglyphs;
+ / make sure this isn't negative as we're going to add 4 later / + if ( limit < 0 ) + { + error = FTTHROW( InvalidArgument ); + goto Exit; + } + / construct an outline structure for / / communication with TTVaryApplyGlyphDeltas' / outline.npoints = (short)( gloader->current.numsubglyphs + 4 );
Marc.
On 2025-03-13 16:50, Vulnerability Disclosure wrote: In the following change
+ if ( FTQNEWARRAY( outline.points, limit + 4 ) || + FTQNEWARRAY( outline.tags, limit ) || + FTQNEWARRAY( outline.contours, limit ) || + FTQNEWARRAY( unrounded, limit + 4 ) )
The out of bounds write requires a short integer overflow with a limit value of 0xFFFD - 0xFFFF. In the patch when we change the second call to FTQNEWARRAY to remove the addition of +4 the size value is now negative and the call to FTQNEWARRAY call will fail with an error code causing the logic to short circuit and prevent the out of bounds write from occurring. While limit is still signed the security risk is mitigated by the early exit condition.
If we also want to make the limit variable unsigned, we can additionally patch based off the following FreeType commit:
https://gitlab.freedesktop.org/freetype/freetype/-/commit/73720c7c9958e87b3d134a7574d1720ad2d24442
Marc.
On Thu, 2025-03-13 at 20:50 +0000, Vulnerability Disclosure wrote: In the following change
+ if ( FTQNEWARRAY( outline.points, limit + 4 ) || + FTQNEWARRAY( outline.tags, limit ) || + FTQNEWARRAY( outline.contours, limit ) || + FTQNEWARRAY( unrounded, limit + 4 ) )
The out of bounds write requires a short integer overflow with a limit value of 0xFFFD - 0xFFFF. In the patch when we change the second call to FTQNEWARRAY to remove the addition of +4 the size value is now negative and the call to FTQNEWARRAY call will fail with an error code causing the logic to short circuit and prevent the out of bounds write from occurring. While limit is still signed the security risk is mitigated by the early exit condition.
If we also want to make the limit variable unsigned, we can additionally patch based off the following FreeType commit:
https://gitlab.freedesktop.org/freetype/freetype/-/commit/73720c7c9958e87b3d134a7574d1720ad2d24442 As a follow-up to that (sorry to keep trickling in information) - it turns out a third commit is required
https://gitlab.freedesktop.org/freetype/freetype/-/commit/c71eb22dde1a3101891a865fdac20a6de814267d
FTQNEWARRAY does not do the right thing without this commit, as it was calling FTMEMNEWARRAY instead of FTMEMQNEWARRAY
The fixes I'm working with both the Meta security folks and the EL community (CentOS / AlmaLinux) can be tracked herehttps://gitlab.com/redhat/centos-stream/rpms/freetype/-/mergerequests/8/diffs
https://gitlab.com/CentOS/Hyperscale/rpms/freetype/-/commits/c9s-hs?reftype=heads
(we've had to fix it several times in Hyperscale too)
I've tried to keep it well documented so hopefully it's of use to those trying to patch older releases such as 2.10.4
Best regards,
-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
Hi Marc,
On Thu, Mar 13, 2025 at 10:50:38AM -0400, Marc Deslauriers wrote: Hi,
On 2025-03-12 16:57, Michel Lind wrote: Description:
An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
https://www.facebook.com/security/advisories/cve-2025-27363
This commit fixes most of the issue - except limit is still signed short - but needs to be redone if you're backporting to 2.10.4
https://gitlab.freedesktop.org/freetype/freetype/-/commit/ef636696524b081f1b8819eb0c6a0b932d35757d Perhaps I need more coffee this morning, but I'm having trouble consolidating that patch with the description. If "limit" is the signed short, what is the unsigned long? It is related to this: https://gitlab.freedesktop.org/freetype/freetype/-/commit/73720c7c9958e87b3d134a7574d1720ad2d24442 see https://gitlab.freedesktop.org/freetype/freetype/-/issues/1322#note2822105 . The commit self is only in 2.13.3. Also, if this is meant as the fix:
- if ( FTNEWARRAY( points, limit + 4 ) || - FTNEWARRAY( tags, limit + 4 ) || - FTNEWARRAY( contours, limit + 4 ) || - FTNEWARRAY( unrounded, limit + 4 ) ) + if ( FTQNEWARRAY( outline.points, limit + 4 ) || + FTQNEWARRAY( outline.tags, limit ) || + FTQNEWARRAY( outline.contours, limit ) || + FTQNEWARRAY( unrounded, limit + 4 ) )
...not only would the remaining + 4 wrap around too, but FTNEWARRAY already checks for a value < 0, so I'm not sure that is it.
What am I not seeing? Do you have already working backport set for 2.12.1 based version?
Regards, Salvatore
In the following change
+ if ( FTQNEWARRAY( outline.points, limit + 4 ) || + FTQNEWARRAY( outline.tags, limit ) || + FTQNEWARRAY( outline.contours, limit ) || + FTQNEWARRAY( unrounded, limit + 4 ) )
The out of bounds write requires a short integer overflow with a limit value of 0xFFFD - 0xFFFF. In the patch when we change the second call to FTQNEWARRAY to remove the addition of +4 the size value is now negative and the call to FTQNEWARRAY call will fail with an error code causing the logic to short circuit and prevent the out of bounds write from occurring. While limit is still signed the security risk is mitigated by the early exit condition.
If we also want to make the limit variable unsigned, we can additionally patch based off the following FreeType commit:
https://gitlab.freedesktop.org/freetype/freetype/-/commit/73720c7c9958e87b3d134a7574d1720ad2d24442
Hi,
On 2025-03-12 16:57, Michel Lind wrote: Description:
An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
https://www.facebook.com/security/advisories/cve-2025-27363
This commit fixes most of the issue - except limit is still signed short - but needs to be redone if you're backporting to 2.10.4
https://gitlab.freedesktop.org/freetype/freetype/-/commit/ef636696524b081f1b8819eb0c6a0b932d35757d
Also, if this is meant as the fix:
- if ( FTNEWARRAY( points, limit + 4 ) || - FTNEWARRAY( tags, limit + 4 ) || - FTNEWARRAY( contours, limit + 4 ) || - FTNEWARRAY( unrounded, limit + 4 ) ) + if ( FTQNEWARRAY( outline.points, limit + 4 ) || + FTQNEWARRAY( outline.tags, limit ) || + FTQNEWARRAY( outline.contours, limit ) || + FTQNEWARRAY( unrounded, limit + 4 ) ) What am I not seeing?
Thanks,
Marc.
Thank you for sharing this and for your work on piecing together the commits needed to backport to 2.10.4.
On Wed, Mar 12, 2025 at 8:16 PM Michel Lind <michel () michel-slm name> wrote: severity: high (CVSS 3.1: 8.1)
Affected versions: <= 2.13.0
Description:
An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
https://www.facebook.com/security/advisories/cve-2025-27363
This commit fixes most of the issue - except limit is still signed short - but needs to be redone if you're backporting to 2.10.4
https://gitlab.freedesktop.org/freetype/freetype/-/commit/ef636696524b081f1b8819eb0c6a0b932d35757d
Per repology some Linux distributions are affected
https://repology.org/project/freetype/versions
- Amazon Linux 2 - Debian stable / Devuan - RHEL / CentOS Stream / Alma Linux / etc. 8 and 9 - GNU Guix - Mageia - OpenMandriva - openSUSE Leap - Slackware - Ubuntu 22.04
(The list above might not be exhaustive)
Best regards,
-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
I don't know much about this bug, which seems to have been announced by Facebook yesterday.
https://nvd.nist.gov/vuln/detail/CVE-2025-27363 An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild. The latest version of FreeType is 2.13.3 which is NOT affected, according to the announcement. Recent distro versions (e.g. Ubuntu 24.04 with 2.13.2) also look safe.
However, older distro versions seem to have affected libraries. For example Debian Bookworm has "2.12.1+dfsg-5+deb12u3", which is less than "2.13.0".
The bug would not be too concerning if people only used trusted fonts, as used to be routine. But webpages now embed fonts, and the affected "variable font files" format is widely used in browsers. It allows parametric adjustment of font properties, described here:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSSfonts/Variablefontsguide
However, it looks like the browsers themselves might be embedding unaffected recent versions of FreeType. For example, I see Mozilla have a commit with the message: Bug 1912903 - Update freetype2 to 2.13.3. https://github.com/mozilla/gecko-dev/commit/026f6a947085020cd189dd9af3da00be433a44f8
I know there's some tension between bundling and unbundling tendencies in the packaging of browsers, so I am not sure how exposed anyone is.
Anyway, I don't see patches for 2.11.x and 2.12.x in stable/LTS releases, and the FreeType website seems pretty quiet about this.
Douglas
severity: high (CVSS 3.1: 8.1)
Affected versions: <= 2.13.0
Description:
An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
https://www.facebook.com/security/advisories/cve-2025-27363
This commit fixes most of the issue - except limit is still signed short - but needs to be redone if you're backporting to 2.10.4
https://gitlab.freedesktop.org/freetype/freetype/-/commit/ef636696524b081f1b8819eb0c6a0b932d35757d
Per repology some Linux distributions are affected
https://repology.org/project/freetype/versions
- Amazon Linux 2 - Debian stable / Devuan - RHEL / CentOS Stream / Alma Linux / etc. 8 and 9 - GNU Guix - Mageia - OpenMandriva - openSUSE Leap - Slackware - Ubuntu 22.04
(The list above might not be exhaustive)
Best regards,
-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
FreeType 2.8.1 has a signed integer overflow in cf2doFlex in cff/cf2intrp.c.
FreeType commit 1e2eb65048f75c64b68708efed6ce904c31f3b2f was discovered to contain a heap buffer overflow via the function sfntinitface.
FreeType commit 53dfdcd8198d2b3201a23c4bad9190519ba918db was discovered to contain a segmentation violation via the function FNTSizeRequest.
FreeType commit 22a0cccb4d9d002f33c1ba7a4b36812c7d4f46b5 was discovered to contain a segmentation violation via the function FTRequestSize.
Impact A memory corruption bug(Heap overflow) in the FreeType font rendering library.
This can be exploited by attackers to execute arbitrary code by using specially crafted fonts with embedded PNG images .
As per https://www.secpod.com/blog/chrome-zero-day-under-active-exploitation-patch-now/
Google is aware of reports that an exploit for CVE-2020-15999 exists in the wild.
Patches Upgrade to 85.3.130 or higher
References - https://www.secpod.com/blog/chrome-zero-day-under-active-exploitation-patch-now/ - https://www.zdnet.com/article/google-releases-chrome-security-update-to-patch-actively-exploited-zero-day/ - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999 - https://magpcss.org/ceforum/viewtopic.php?f=10&t=17942
To review the CEF/Chromium patch see https://bitbucket.org/chromiumembedded/cef/commits/cd6cbe008b127990036945fb75e7c2c1594ab10d
FreeType before 2.6.2 has a heap-based buffer over-read in ttcmap14validate in sfnt/ttcmap.c.
FreeType before 2.6.1 has a buffer over-read in skipcomment in psaux/psobjs.c because psparserskipPStoken is mishandled in an FTNewMemoryFace operation.
FreeType before 2.6.1 has a heap-based buffer over-read in T1GetPrivateDict in type1/t1parse.c.
In FreeType before 2.6.1, a buffer over-read occurs in type1/t1parse.c on function T1GetPrivateDict where there is no check that the new values of cur and limit are sensible before going to Again.
An issue was discovered in FreeType 2 through 2.9. A NULL pointer dereference in the InsGETVARIATION() function within ttinterp.c could lead to DoS via a crafted font file.