fix: heap out-of-bounds read in parse_number_expression (#446)

[marcobambini]

Fixes #446.

What changed

parse_number_expression decided whether a number literal used a 0b/0o/0x prefix by testing value[0] == '0' and then unconditionally reading value[1], with no check that the token is at least 2 bytes long. This adds a token.bytes > 1 guard.

Why

token.value points directly into the caller's source buffer (lexer->buffer + lexer->offset in gravity_lexer.c) and is not separately zero terminated — the lexer treats the buffer as exactly len bytes and bounds-checks every peek. So when the final token of the source is a lone 0, value[1] reads one byte past the end of the buffer.

Reproduced under ASan by passing an exact-size malloc(3) buffer containing x=0 to gravity_compiler_run:

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000d3
READ of size 1 at 0x6020000000d3 thread T0
    #0 parse_number_expression gravity_parser.c:684
    #1 parse_literal_expression gravity_parser.c:904
    #2 parse_precedence         gravity_parser.c:1074
    ...
0x6020000000d3 is located 0 bytes after 3-byte region [0x6020000000d0,0x6020000000d3)

Notes for the reviewer

Scope is narrower than the issue title suggests. The CLI is not affected: file_read allocates fsize + 1 and sets buffer[fsize] = 0, so value[1] lands on the in-bounds terminator. I confirmed this with an ASan-built gravity on a file containing exactly var x=0 with no trailing newline — clean. gravity -i is fine for the same reason (argv is terminated). The exposure is to embedders calling gravity_compiler_run / gravity_vm_loadbuffer with a non-terminated exact-length buffer, which the explicit size_t len parameter permits — that includes the fuzz harness that found this.

Impact is capped at the single byte; there is no escalation path. If the out-of-bounds byte happens to be b/o/x, the decoders get called with token.bytes == 1 and token.bytes - 2 underflows to 0xFFFFFFFF on uint32_t. All three bail on the length before touching memory (number_from_bin returns 0 for len > 64, number_from_oct / number_from_hex for len > 24), so nothing is dereferenced and the literal still decodes to the correct 0. I checked all four trailing-byte variants under ASan. The reporter's "Medium" rating is fair, arguably generous.

gravity_parser.c:378 (&token.value[2] in decode_number_binary) is the only other indexed token.value read in the tree — technically UB pointer arithmetic on a 1-byte token, but never dereferenced thanks to that same guard.

Testing

• ASan clean on x=0 and on a bare 0
• 0xFF, 0b101, 0o17 still decode correctly
• Full unit suite: 350/350 passing

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gravity	Ready	Preview	Aug 5, 2026 7:22am