Skip to content

fix: guard Delete against out-of-range endOffset+tokEnd on fuzz input#282

Open
SAY-5 wants to merge 1 commit intobuger:masterfrom
SAY-5:fix/delete-endoffset-bounds-274
Open

fix: guard Delete against out-of-range endOffset+tokEnd on fuzz input#282
SAY-5 wants to merge 1 commit intobuger:masterfrom
SAY-5:fix/delete-endoffset-bounds-274

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented Apr 21, 2026

What

Fixes #274.

Delete's nested-key branch assumed that endOffset+tokEnd (the byte after the found value's closing token) always stayed inside the input buffer. Fuzz-generated or truncated input can leave the computed index one-past the buffer, and the subsequent data[endOffset+tokEnd] read panics with:

panic: runtime error: index out of range [9] with length 9

killing the whole process before any caller could recover - this is how Delete surfaces as a deadly signal under libFuzzer / oss-fuzz.

Fix

Bail out early and return the original buffer unchanged when the next-byte index is out of range. That matches the correct no-op semantic: 'there is nothing after the match to remove', so the caller gets their input back, no panic, no partial delete. The happy path is unchanged.

Verification

Locally on macOS, go 1.26.2:

  • gofmt -s -l parser.go: clean
  • go vet ./...: clean (the existing bytes_unsafe_test.go:26 reflect.StringHeader note is pre-existing and untouched by this PR)
  • go test -race -count=1 ./...: pass

Closes #274

Delete's nested-key branch assumed that endOffset+tokEnd (the byte
after the found value's closing token) always stayed inside the
input buffer. Fuzz-generated or truncated input can leave the
computed index one-past the buffer, and the subsequent
data[endOffset+tokEnd] read panicked with 'index out of range',
killing the whole process before any caller could recover - this
is how Delete surfaced as a deadly signal under libFuzzer (buger#274).

Bail out early and return the original buffer unchanged when the
next-byte index is out of range. That is equivalent to 'there is
nothing after the match to remove', which is the correct
no-op semantic here: the caller gets their input back, no panic,
no partial delete.

Closes buger#274

Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
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.

Oob (index out of range)

1 participant