On 2025-03-13 16:50, Vulnerability Disclosure wrote:
In the following change
+ if ( FT_QNEW_ARRAY( outline.points, limit + 4 ) ||
+ FT_QNEW_ARRAY( outline.tags, limit ) ||
+ FT_QNEW_ARRAY( outline.contours, limit ) ||
+ FT_QNEW_ARRAY( 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 FT_QNEW_ARRAY
to remove the addition of +4 the size value is now negative and the call to
FT_QNEW_ARRAY 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.
Oh I see, this commit wasn't written as a security fix, it just happens to now
trigger the negative number check in FT_QNEW_ARRAY which prevents the issue from
happening.
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
Ultimately this is the proper fix, but there are a whole slew of other changes
that went into 2.13.3 to go along with it that change signed short to unsigned
short in a bunch of other places, such as FT_Outline. Just backporting that
commit will prevent limit from going negative and the check in FT_QNEW_ARRAY
will no longer work.
Marc.
