Skip to content

loader/obj: guard against out-of-range face indices to prevent panic - #322

Open
ChrisJr404 wants to merge 1 commit into
g3n:masterfrom
ChrisJr404:fix-obj-face-index-panic
Open

loader/obj: guard against out-of-range face indices to prevent panic#322
ChrisJr404 wants to merge 1 commit into
g3n:masterfrom
ChrisJr404:fix-obj-face-index-panic

Conversation

@ChrisJr404

Copy link
Copy Markdown

Problem

Loading an OBJ file whose face lines reference vertex/UV/normal indices outside the range of the data actually present in the file causes a panic (index out of range) rather than an error.

In NewGeometry, the indices parsed from f lines are handed straight to math32.ArrayF32.GetVector3/GetVector2, which do unchecked slice access:

dec.Vertices.GetVector3(3*face.Vertices[idx], &vec3)

Nothing verifies that the index is within the decoded Vertices/Normals/Uvs arrays. A file such as:

v 0 0 0
v 1 0 0
v 0 1 0
f 1 2 999999

panics on the standard load path (obj.Decode / DecodeReader followed by NewGroup/NewGeometry). Large negative indices (e.g. f -100 -100 -100) hit the same problem via the relative-index math. Since OBJ files are frequently loaded from untrusted or user-supplied sources, a single malformed file can crash the host program.

Fix

Bounds-check each vertex/UV/normal index against the corresponding array before dereferencing it, and return an error from NewGeometry instead of panicking. The check uses the element count (len/stride) rather than stride*index, so it can't overflow on 32-bit platforms. Valid files are completely unaffected.

Tests

Added loader/obj/obj_test.go covering out-of-range vertex/UV/normal indices (including a large negative index) and a well-formed file that must still build geometry without error. The out-of-range tests panic without this change and pass with it.

go test ./loader/obj/, go vet, and gofmt are clean.

A face line whose vertex/uv/normal index points past the decoded arrays
(e.g. "f 1 2 999999", or a large negative index) caused NewGeometry to
panic with an index-out-of-range while copying vertices, since the indices
read straight from the OBJ were passed to ArrayF32.GetVector3/GetVector2
without any bounds check. A malformed or malicious .obj is enough to crash
a program that loads it.

Validate each index against the corresponding array length before use and
return an error instead of panicking. The bounds are checked with the
element count (len/stride) rather than stride*index so the check itself
cannot overflow. Adds tests covering the out-of-range cases and a valid
file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant