Multiple memory corruption vulnerabilities in OBJ parsing (stack overflow, heap OOB, integer overflow)

[ByamB4]

Hi, I was doing some fuzz testing on small OBJ parsing libraries and ran into several crashes in objpar. After looking at the source, I found a few related issues:

1. Stack buffer overflow in numeric parsing (most critical)

In objpar_internal_v() (and the vn, vt, f variants), there's a char str[32] on the stack that gets filled without any bounds check:

char str[32];                      // line 389
// ...
while (c0 > 0x2C && c0 < 0x3A)
{
    str[str_size++] = c0;          // lines 424-428 — no bounds check
    c0 = p_string[++index];
}

A vertex line with a long numeric value (33+ chars like v 123456789012345678901234567890123 0 0) writes past the stack buffer. Same pattern in all four parsing functions.

2. All scan loops ignore string_size — heap OOB read

The string_size parameter is passed to every parsing function but never actually used in the scan loops. They all scan for \n/\r without any bounds check:

while (c0 != '\n' && c0 != '\r')   // line 422 — no check against string_size

If the input doesn't end with a newline (which is pretty common for OBJ files), every function reads past the buffer until it happens to hit a newline byte somewhere in memory.

3. Face index 0 causes unsigned underflow → heap OOB read

In objpar_build_mesh() at line 340:

idx = (p_faces[index + OBJPAR_V_IDX] - 1);   // unsigned int
idx *= position_width;
// ...
p_position[j] = p_positions[idx + j];         // OOB read

OBJ face indices are 1-based, so the code subtracts 1. But if a face references vertex 0 (e.g., f 0/0/0 1/1/1 1/1/1), the subtraction wraps to 0xFFFFFFFF and the subsequent array access goes way out of bounds.

4. Heap OOB write when vertex has more components than expected

vertex_width is determined from the first vertex line. If a later line has more components, comp_count exceeds vertex_width and p_vertex[comp_count] writes past the allocated vertex buffer (line 434).

5. Integer overflow in buffer size calculation

The buffer sizes at lines 183-188 are products of multiple unsigned int values with no overflow check. With a large enough face count, the multiplication can wrap to a small value, causing a tiny allocation followed by a massive heap overflow.

Environment

• Discovered via: fuzz testing + manual code audit
• objpar version: latest (HEAD)
• Affects all platforms

Let me know if you'd like any additional details or a PoC file for any of these.