soke-0xai/executorch-pte-unicode-abort-poc-huntr

ExecuTorch: malformed .pte with non-UTF-8 strings aborts the Python loader process

A one-byte mutation of a valid .pte file — corrupting the FlatBuffer program identifier (or the name of an output tensor, or an operator name) from valid ASCII to an invalid UTF-8 leading byte (0xff) — causes executorch.extension.pybindings._portable_lib to terminate the entire Python process via an uncaught pybind11::error_already_set wrapping a UnicodeDecodeError, instead of returning a catchable Python exception.

terminate called after throwing an instance of 'pybind11::error_already_set'
  what():  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 23: invalid start byte
Fatal Python error: Aborted

Confirmed the C++ loader's own validation logic is otherwise working correctly — an ASCII-but-wrong identifier (e.g. ET1X) is rejected cleanly with a catchable RuntimeError. Only identifiers/strings containing a byte that is invalid UTF-8 (not just "wrong ASCII text") take the path that aborts the process. This reproduces identically for the program identifier itself (crashes in _load_program_from_buffer) and, separately, for an output-tensor name or operator name inside an otherwise-loadable program (crashes later, in load_method("forward"), inside operator_registry.cpp) — so this is a class of unsanitized-string-in-error-path bug across multiple FlatBuffer string fields, not a single isolated header check.

Verified today (2026-07-03) on macOS arm64, Python 3.12.11, with fresh isolated installs of executorch==1.3.1 and torch==2.12.1 — all three reproducers (et_min_unicode_abort.pte, out_name_ff.pte, op_name_ff.pte) still abort with the same stack trace pattern and SIGABRT. Checked for prior art: no exact duplicate found in ExecuTorch's own issue tracker; pybind11's changelog (2.10.1) fixed a related-sounding "surrogate character in exception message aborts process" bug, but that's specifically about UTF-16 surrogate codepoints — the crash here is triggered by a plain invalid-UTF-8 leading byte ('utf-8' codec can't decode byte 0xff ... invalid start byte), a different and, per the current reproduction, still-live path.

Honest scope: this is a deterministic process-abort / denial-of-service, not demonstrated memory corruption or RCE — confirmed by testing the alternate _load_for_executorch_from_buffer entry point, which handles the same mutant file without crashing (so this is specifically a Python-binding error-surfacing gap, not a core C++ runtime memory-safety issue). Impact is real for any application that loads untrusted/external .pte files through the Python bindings — local model-inspection tools, CI pipelines, model registries/scanners, or any service accepting user-uploaded ExecuTorch models.

Full technical detail, all four reproducer variants, and recommended fix in report_draft.md. Submission draft in submission.md. Local reproduction helper: verify_executorch_unicode_abort.py.