JS_ReadObject: reject empty bytecode and validate ROM atom index

[iliasabk]

Issues

Fixes #548 and fixes #550 — two out-of-bounds reads in the JS_ReadObject bytecode-deserialization path, both reported by sigdevel with deterministic ASan-verified PoCs at commit 04be246 (VERSION 2026-06-04).

Root causes

#548 — unvalidated runtime atom index in ROM_DATA mode (quickjs.c:38652)

In JS_ReadFunctionBytecode, the atom-fixup loop reads the 4-byte opcode operand with get_u32(bc_buf + pos + 1). With JS_READ_OBJ_ROM_DATA, that operand is used directly as a runtime atom index: JS_DupAtom(ctx, (JSAtom)idx). A crafted operand (e.g. 0x400) is not a constant atom, so JS_DupAtom indexes rt->atom_array[idx] — in the reporter's ASan log, 2504 bytes past the 5696-byte atom table (heap-buffer-overflow READ of size 8). An index that lands on a free-list slot is worse: js_rc(p)->ref_count++ increments through a tagged pseudo-pointer, a wild write.

#550 — zero-length bytecode accepted (quickjs.c:38792 → 17878)

JS_ReadFunctionTag accepts a function whose declared byte_code_len is 0: the header fields parse, no bytecode bytes are copied, and byte_code_buf points at the end of the 96-byte allocation. JS_EvalFunction then instantiates and executes the value; JS_CallInternal starts the interpreter with pc = b->byte_code_buf and the first opcode fetch reads *pc — one byte past the end of the heap buffer (ASan heap-buffer-overflow READ, reporter-verified 5/5 on Linux).

A negative byte_code_len is additionally dangerous: function_size += bc.byte_code_len shrinks the allocation below the header size and bc_get_buf then copies with a negative length.

Fix

• Reject byte_code_len <= 0 in JS_ReadFunctionTag with a SyntaxError. A real function always serializes to at least one opcode (return), so empty bytecode can only be malformed input; rejecting also closes the negative-length allocation shrink.
• In the ROM_DATA atom-fixup branch, validate idx before JS_DupAtom: reject operands that are neither constant atoms (__JS_AtomIsConst) nor live entries of rt->atom_array (bounds check plus free-list tag-bit check), throwing SyntaxError and truncating b->byte_code_len at pos so free_bytecode_atoms only unwinds the atoms already duplicated — the same cleanup contract the bc_idx_to_atom failure path uses.

Verification

Built the reporter's poc_driver against this branch with ASan and ran both base64 reproducers:

• [[Bug]Heap-buffer-overflow read in JS_DupAtom: ROM_DATA bytecode uses an unvalidated atom index (rt->atom_array OOB) (CWE-125) #548 (AgUADAAAAAAAAAABAAAABQAEAAQAAA==): unpatched crashes with heap-buffer-overflow READ of size 8 in JS_ReadFunctionBytecode on the atom table; patched rejects with SyntaxError: invalid atom index (pos=21).
• [Bug]Heap-buffer-overflow read in JS_CallInternal: executing a function with empty (byte_code_len == 0) bytecode reads the first opcode past the buffer (CWE-125) #550 (AQUADAAAAAAAAAABAAAAAAA=): unpatched runs the interpreter on a zero-length buffer and reaches invalid opcode after reading past the allocation (the reporter's Linux ASan log documents the OOB read at JS_CallInternal); patched rejects at deserialization with SyntaxError: invalid bytecode length.
• make test: all tests pass (closure, language, builtin, loop, bigint, cyclic_import, worker, std, rw_handler).
• Round-trip sanity: JS_Eval(..., JS_EVAL_FLAG_COMPILE_ONLY) → JS_WriteObject → JS_ReadObject → JS_EvalFunction executes correctly — legitimate bytecode is unaffected.