Fix stack-buffer-overflow in parseLine() on a face line with >16 vertices

[ZUENS2020]

Problem

parseLine() stores face (f) / line (l) vertices into a fixed-size stack array f[TINYOBJ_MAX_FACES_PER_F_LINE] (= 16) with no bounds check. An OBJ face is a legal N-gon with an arbitrary vertex count, so a face line with more than 16 vertices writes past the end of the array — a stack-buffer-overflow WRITE. The guarding assert() is compiled out under -DNDEBUG (release), so there is no runtime protection. With TINYOBJ_FLAG_TRIANGULATE, the triangulation loop also writes command->f[3*n+..] (also size 16) unchecked, overflowing for faces with >7 vertices.

Reachable via the public tinyobj_parse_obj(..., TINYOBJ_FLAG_TRIANGULATE) on a valid OBJ:

f 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

$ clang -fsanitize=address -O2 -DNDEBUG -I. repro.c -o repro && ./repro
==ERROR: AddressSanitizer: stack-buffer-overflow ... WRITE of size 8
SUMMARY: AddressSanitizer: stack-buffer-overflow in tinyobj_parse_obj

(-DNDEBUG matters — it removes the asserts that would otherwise abort in debug.) Found via libFuzzer + ASan; reproduced on a clean clone of master.

Fix

Bound the writes in both the parse loop and the triangulation loop against TINYOBJ_MAX_FACES_PER_F_LINE (extra vertices dropped to preserve memory safety). Minimal memory-safety stop-gap — sizing the buffers for the actual face (an N-gon triangulates to 3*(N-2) indices) would be the complete fix and is probably best done alongside the face/triangulation rework in #60. Normal triangle/quad parsing is unchanged (verified with TINYOBJ_FLAG_TRIANGULATE).

Note

This repo has issues disabled, so filing as a PR. Not a duplicate of #55 (a different sscanf("%s") overflow) or #60 (a triangulation indexing correctness bug in the same area, which does not address this unbounded write).

[syoyo]

you should add regression test

[ZUENS2020]

Added regression tests in test/tinyobj_internal_tests.c (parseLine_face_overflow, parseLine_line_overflow). Both reproduce an AddressSanitizer stack-buffer-overflow on the pre-fix code and pass with the fix.

Writing the l-statement test surfaced a second overflow the first patch missed — the line branch keeps two vertices in f[2] but was still bounded by TINYOBJ_MAX_FACES_PER_F_LINE (16), so l 1 2 3 would write f[2]. It's now bounded to 2. I also relaxed two debug asserts that encoded the old "the whole n-gon always fits" precondition, which the runtime guards now enforce.