Bug: tt_cmap4_char_map_binary() — ttcmap.c ~line 1408
Type: 2-byte OOB heap read (heap-buffer-overflow under ASan)
Root cause: Validator skips idRangeOffset bounds check on last 0xFFFF–0xFFFF sentinel segment; runtime skips limit guard when next==0 (all direct FT_Get_Char_Index calls).
Craft: idRangeOffset[1] = 0xFFFE → p jumps 65,532 bytes past cmap end.

Chrome runs OTS (OpenType Sanitizer) on all @font-face fonts before they reach FreeType. OTS rejects idRangeOffset=0xFFFE → font never reaches FreeType. Dead end for web HTML vector.

poc.html — shows "Font load failed: NetworkError" on all Chrome platforms.

PDFium loads embedded fonts via FT_Open_Face() directly — no OTS. PDFium bundles its own FreeType and uses it on Windows, macOS, Linux, Android (unlike Skia which gates FreeType on is_linux || is_android).

Validated: Chrome PDF viewer opens the file, renders 1 blank page (.notdef) confirming FreeType processed the embedded crafted TTF and executed the OOB read path.
On an ASan Chrome build: heap-buffer-overflow READ 2 … tt_cmap4_char_map_binary

→ poc.pdf (open in Chrome)

==PID== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
READ of size 2 at 0x... thread T0
    #0 tt_cmap4_char_map_binary  sfnt/ttcmap.c:1408
    #1 tt_cmap4_char_index
    #2 FT_Get_Char_Index
    #3 CPDF_CIDFont::GlyphFromCharCode   (PDFium path)
    #4 ...

1. Attacker hosts or emails malicious.pdf
2. Victim opens it in Chrome (any platform — Windows/macOS/Linux/Android)
3. PDFium renders page → calls FT_Open_Face on embedded crafted TTF
4. FreeType looks up glyph for CID 0xFFFF → tt_cmap4_char_map_binary OOBs
5. 2-byte heap read of adjacent memory — info leak / crash under ASan