In the freetype/src/base/ftmac.c file used exclusively to process Mac font files, the following code operating on FOND resources is present (function "parse_fond"):

433:      unsigned short  string_count;
434:      char            ps_name[256];
435:      unsigned char*  names[64];
...
439:      string_count = EndianS16_BtoN( *(short*)(p) );
...
464:          unsigned char*  suffixes = names[style->indexes[face_index] - 1];
465:
466:
467:          for ( i = 1; i <= suffixes[0]; i++ )
468:          {
469:            unsigned char*  s;
470:            size_t          j = suffixes[i] - 1;
471:
472:
473:            if ( j < string_count && ( s = names[j] ) != NULL )
474:            {
475:              size_t  s_len = (size_t)s[0];
476:
477:
478:              if ( s_len != 0 && ps_name_len + s_len < sizeof ( ps_name ) )
479:              {
480:                ft_memcpy( ps_name + ps_name_len, s + 1, s_len );
481:                ps_name_len += s_len;
482:                ps_name[ps_name_len] = 0;
483:              }
484:            }
485:          }

Note that the "names" array is 64 entry long, while the "string_count" variable stores a 16-bit controlled value. In line 473, the value of "j" (which is a controlled 8-bit value) is only checked against string_count but not against 64 (ARRAYSIZE(names)) before being used as an index into names[]. Therefore, it is possible to cause an out-of-bounds read in the "s = names[j]" expression, with j ranging between 64 .. 254 and -1. Further on, the invalid pointer can be further used to obtain a part of the PostScript font name and copy it into "ps_name" in line 480. This can lead to Denial of Service through library crash, or potentially memory disclosure, if the font name can be propagated back to the attacker.

The bug was identified through manual source code review, thus a proof of concept sample is not available at the time of this writing.