Skip to content

fix: validate offset before forming a pointer in ResizeContext::ResizeTable - #9201

Open
prasanna8585 wants to merge 1 commit into
google:masterfrom
prasanna8585:fix/resize-table-oob-offset
Open

fix: validate offset before forming a pointer in ResizeContext::ResizeTable#9201
prasanna8585 wants to merge 1 commit into
google:masterfrom
prasanna8585:fix/resize-table-oob-offset

Conversation

@prasanna8585

Copy link
Copy Markdown

SetString and ResizeAnyVector construct a ResizeContext, which walks the ENTIRE object graph from the root table (not just the field being resized) via ResizeTable, adjusting offsets for the insertion point. For each object-typed field encountered along the way, it read a stored uoffset_t and formed a pointer from it with no validation:

auto ref = offsetloc + ReadScalar<uoffset_t>(offsetloc);

A malformed or corrupted offset in ANY such field — not necessarily the field the caller intended to touch — produces a wild pointer that is then dereferenced in the recursive ResizeTable calls below, causing a crash. Confirmed via a real ASan SEGV in ResizeContext::ResizeTable, reached from SetStringResizeContext::ResizeContextResizeTableResizeTable (recursive) → wild read.

Re-running Verifier immediately before the call does catch this specific corruption, but ResizeTable itself has no independent bounds checking of its own — the same gap AddFlatBuffer had for its root offset before that was fixed directly in the function (commit 21b0332, "Add bounds check for root offset in AddFlatBuffer"), rather than treated as solely the caller's responsibility to have verified beforehand. This applies the same style of fix here: validate the raw offset value against the buffer's bounds using integer arithmetic (checked via subtraction to avoid overflow in the addition itself) before using it to form any pointer, and skip the field rather than crash if it's out of range.

Adds ResizeTableMalformedOffsetTest, mirroring the existing ForAllFieldsReverseTest's structure: it corrupts a sibling object-typed field's stored offset and confirms that resizing an unrelated string field no longer crashes.

Verified: full existing test suite passes under ASan (ALL TESTS PASSED, no sanitizer errors) with the fix applied, including the new regression test.

…eTable

SetString and ResizeAnyVector construct a ResizeContext, which walks
the ENTIRE object graph from the root table (not just the field being
resized) via ResizeTable, adjusting offsets for the insertion point.
For each object-typed field encountered along the way, it read a
stored uoffset_t and formed a pointer from it with no validation:

    auto ref = offsetloc + ReadScalar<uoffset_t>(offsetloc);

A malformed or corrupted offset in ANY such field -- not necessarily
the field the caller intended to touch -- produces a wild pointer
that is then dereferenced in the recursive ResizeTable calls below,
causing a crash (confirmed via a real ASan SEGV in
ResizeContext::ResizeTable).

Re-running Verifier immediately before the call does catch this
specific corruption, but ResizeTable itself has no independent bounds
checking of its own -- the same gap AddFlatBuffer had for its root
offset before that was fixed directly in the function (commit
21b0332, "Add bounds check for root offset in AddFlatBuffer"), rather
than treated as solely the caller's responsibility to have verified.
This applies the same style of fix here: validate the raw offset
value against the buffer's bounds using integer arithmetic (checked
via subtraction to avoid overflow in the addition itself) before
using it to form any pointer, and skip the field rather than crash if
it's out of range.

Adds ResizeTableMalformedOffsetTest, mirroring the existing
ForAllFieldsReverseTest's structure, which corrupts a sibling
object-typed field's stored offset and confirms that resizing an
unrelated string field no longer crashes.
@github-actions github-actions Bot added c++ codegen Involving generating code from schema labels Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c++ codegen Involving generating code from schema

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant