SKIA-0005

Summary

SkOTUtils::RenameFont() rewrites a font’s name table. It sizes the output buffer from the font’s declared table sizes but then copies using the name entry’s declared offset without checking either against the file length or the allocation:

// src/sfnt/SkOTUtils.cpp
size_t oldNameTablePhysicalSize = (SkEndian_SwapBE32(tableEntry.logicalLength) + 3) & ~3; // attacker
size_t oldNameTableOffset       =  SkEndian_SwapBE32(tableEntry.offset);                   // attacker

size_t originalDataSize = fontData->getLength() - oldNameTablePhysicalSize;   // (1) underflow-prone
size_t newDataSize      = originalDataSize + nameTablePhysicalSize;

auto rewrittenFontData = SkData::MakeUninitialized(newDataSize);
SK_OT_BYTE* data = static_cast<SK_OT_BYTE*>(rewrittenFontData->writable_data());

if (fontData->read(data, oldNameTableOffset) < oldNameTableOffset) {          // (2) writes oldNameTableOffset
    return nullptr;                                                           //     bytes into newDataSize buf
}
...
if (fontData->read(data + oldNameTableOffset,
                   originalDataSize - oldNameTableOffset) < ...) { ... }       // (3) also unchecked

Nothing enforces the SFNT invariant oldNameTableOffset + oldNameTablePhysicalSize <= getLength() (nor oldNameTableOffset <= newDataSize). A crafted font whose name entry declares a large logicalLength (shrinking newDataSize) and a large offset (the read count) makes read(data, oldNameTableOffset) write oldNameTableOffset attacker bytes into the smaller newDataSize buffer — a heap buffer overflow write with attacker-controlled length and contents. (When oldNameTablePhysicalSize > getLength(), line (1) additionally underflows size_t, which can wrap newDataSize to a tiny value and widen the overflow.)

Reproduction

pocs/skia/skottable/SKIA-0005/poc_renamefont_oobwrite.cc builds a 1000-byte SFNT with a single name TableDirectoryEntry { offset = 900, logicalLength = 980 } and calls RenameFont(stream, "X", 1).

SKIA=~/Projects/skia pocs/skia/skottable/verify.sh

ASan (clang-12, real SkOTUtils.cpp):

calling SkOTUtils::RenameFont (font=1000 bytes, name offset=900, logicalLength=980)...
==ERROR: AddressSanitizer: heap-buffer-overflow ... WRITE of size 900
  #2 SkMemoryStream::read   SkStream.cpp:349
  ... sk_careful_memcpy <- SkOTUtils::RenameFont
0x6100000000fc is located 0 bytes to the right of 188-byte region
  ... SkData::MakeUninitialized(188)

newDataSize = (1000 − 980) + nameTablePhysicalSize(168) = 188; the read of 900 bytes overflows it by 712 bytes.

Root cause

The function trusts the attacker-controlled name table directory entry (offset, logicalLength) to be internally consistent with the file, but never validates it. Fix: before allocating/copying, require oldNameTableOffset <= getLength(), oldNameTablePhysicalSize <= getLength(), and oldNameTableOffset + oldNameTablePhysicalSize <= getLength() (reject otherwise), and use checked arithmetic (SkSafeMath) for originalDataSize / newDataSize.

Verification evidence

verification.verified: true, evidence: public_api_reachable. Verified at two levels:

Public API, end-to-end (Windows GDI, 2026-06-23) — the rung that counts. Skia 488a6fc was built for Windows with MSVC cl.exe 14.38 + GN sanitize="ASAN" (is_clang=false → /fsanitize=address; cl auto-links the ASan runtime, so no clang-cl/LLVM is needed), GDI font backend enabled. The harness pocs/skia/skottable/SKIA-0005/skia0005_gdi_harness.cc (GN target //:skia0005_gdi_harness) drives the public API SkFontMgr_New_GDI()->makeFromStream(malicious_verdana.ttf, /*ttcIndex=*/0). ASan fires a heap-buffer-overflow WRITE of 243300 bytes, 0 bytes past a 280-byte region, with the full public-API stack:

==ERROR: AddressSanitizer: heap-buffer-overflow  WRITE of size 243300
  #1 SkMemoryStream::read              src/core/SkStream.cpp:349
  #2 SkOTUtils::RenameFont             src/sfnt/SkOTUtils.cpp:91
  #3 create_from_stream                src/ports/SkFontHost_win.cpp:1809
  #4 SkFontMgrGDI::onMakeFromStreamIndex src/ports/SkFontHost_win.cpp:2290
  #5 SkFontMgr::makeFromStream         src/core/SkFontMgr.cpp:189
  #6 main   ← public API
0 bytes to the right of 280-byte region
  ... SkData::MakeUninitialized <- SkOTUtils::RenameFont  SkOTUtils.cpp:88

Full log: pocs/skia/skottable/SKIA-0005/asan_gdi_e2e.txt. The source-only reachability claim is now a runtime fact through the real public GDI API. Fix confirmed end-to-end too: with fix.patch applied and rebuilt, the same crafted font is rejected (RenameFont→null → makeFromStream→null typeface, no ASan error), while a legitimate verdana.ttf still loads.

Cheap harness (Linux/clang-12, no GN) — harness_reproduced, corroborating. The PoCs in verify.sh link the actual src/sfnt/SkOTUtils.cpp (not a logic replica) and ASan reports the same heap OOB write inside the shipping RenameFont via SkMemoryStream::read — RenameFont is platform-agnostic, so this reproduces the core bug with trivial cost.

Impact

High (scoped to the Windows GDI font backend). This is an attacker-controlled-length, attacker-controlled-content heap buffer overflow write during font loading. Call chain: SkFontMgr_GDI::onMakeFromStream / onMakeFromData / onMakeFromFile (SkFontHost_win.cpp:2285-2307) → create_from_stream (:1799) → SkOTUtils::RenameFont (:1809), which renames a stream-loaded font before AddFontMemResourceEx. Any SkFontMgr_New_GDI()->makeFromData/Stream/File(<untrusted font>) reaches it.

Reachability caveat (important, and a correction to an earlier overstatement): this is the GDI backend ONLY — RenameFont has exactly one caller in the tree and the DirectWrite backend (SkScalerContext_win_dw) does not call it. Modern Chrome on Windows uses DirectWrite, so default Chrome web-font loading does NOT hit this. It affects Windows apps/embedders configured with the GDI font manager (legacy Chromium; some Skia-based document/SVG/HTML-to-image renderers; embedded Windows software) that load untrusted fonts via stream/data/file (web @font-face, document-embedded fonts, user-supplied font files). Within that scope it is a controlled-data heap-corruption-write primitive (potential RCE, subject to heap layout/mitigations). RenameFont is also a public SkOTUtils API, so any embedder that renames untrusted fonts is exposed. Worth an upstream report with the bounds-check fix above (one caller, simple fix).

Fix (verified) & upstream report

A one-hunk fix — reject the entry unless oldNameTableOffset + oldNameTablePhysicalSize <= getLength() before allocating/copying — is in pocs/skia/skottable/SKIA-0005/fix.patch. Verified at both levels: with the patch applied, the Linux PoCs return nullptr (malformed font rejected) and ASan reports no error (rebuilt via verify.sh); AND end-to-end on the Windows GDI ASan build, the public-API harness rejects malicious_verdana.ttf (null typeface, no ASan error) while a legitimate verdana.ttf still loads — confirming the fix is correct and not over-broad. A submission-ready writeup is in pocs/skia/skottable/SKIA-0005/UPSTREAM-REPORT.md (Skia tracker, Skia > Fonts, Security template), with the completed Windows end-to-end verification recorded. Disclosed upstream 2026-06-23 — Skia issue tracker issue 527031551 (Skia > Fonts, Security template); made public 2026-06-24 (issue opened to public view; embargo lifted). Status stays verified pending a CVE/vendor ack (the build gates disclosed on a cve); promote to disclosed once an ID is assigned and to patched when the fix lands.