• src/syncterm/wren/vm/wren

    From Deuc¿@VERT to Git commit to main/sbbs/m on Thursday, April 30, 2026 10:38:00
    https://gitlab.synchro.net/main/sbbs/-/commit/d938e6f021a3c87c0cd7553f
    Modified Files:
    src/syncterm/wren/vm/wren_compiler.c
    Log Message:
    SyncTERM: harden vendored Wren compiler against fuzzer-found crashes

    Five compiler-level bugs reported by oneafter against upstream
    wren-lang/wren (issues #1217-#1221). All five reproducers exit cleanly
    with compile errors after the fix under -fsanitize=address,undefined.

    #1217 Ä peekChar OOB in readRawString: the loop unconditionally peeked
    two characters after nextChar(), so consuming the buffer's terminating
    '\0' caused a 1-byte read past the source allocation. The "consume the
    closing two quotes" calls after the loop did the same on the
    unterminated path. Hoist the c=='\0' check above the peeks; only run
    the trailing two-quote consume when the loop actually saw the closing triple-quote.

    #1218 Ä stack exhaustion via deep nesting: the recursive descent
    parser had no depth limit. ~300 frames of definition/finishBlock/ statement/forStatement/loopBody corrupted the C stack and ASAN
    reported it as a heap-buffer-underflow in resolveLocal's memcmp. Add MAX_RECURSION_DEPTH (256) plus a recursionDepth counter on Parser;
    gate statement() and expression() at the entry point.

    #1219 Ä emitOp stackEffects[] OOB: validateNumParameters reports an
    error at arity == MAX_PARAMETERS+1 but does not stop or clamp, so
    callSignature emits (Code)(CODE_CALL_0 + arity) past CALL_16/SUPER_16
    and emitOp reads stackEffects[] beyond its 77 entries. Clamp arity in callSignature and callMethod, and add a sizeof-based bounds guard in
    emitOp as the safety net.

    #1220 Ä NULL deref in getByteCountForArguments: after error recovery
    emits malformed bytecode, endLoop's body walk treats arg bytes as
    opcodes; a CODE_CLOSURE byte then dereferences constants[] with a
    bogus index against an empty (NULL data) constants buffer. Skip the
    walk entirely when parser->hasError is set Ä the function is going to
    be discarded anyway.

    #1221 Ä vsprintf overflow in printError: a 159-byte stack buffer was
    filled by sprintf+vsprintf with no length checks. Attacker-controlled identifiers (method/variable names ó MAX_VARIABLE_NAME * actual
    length) can blow the buffer via formats like "Method '%s' is already
    defined." Switch to snprintf+vsnprintf with remaining-bytes
    accounting; drop the now-redundant ASSERT.

    Thanks to oneafter for the careful fuzzing reports and reproducers.

    Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/m on Saturday, May 02, 2026 15:47:00
    https://gitlab.synchro.net/main/sbbs/-/commit/3e714141aa290190f0f09cdd
    Modified Files:
    src/syncterm/wren/vm/wren_vm.c
    Log Message:
    Wren: close upvalues on fiber abort to prevent UAF

    runtimeError() unwound the caller chain without calling
    closeUpvalues() on the aborting fibers. Every other code path
    that ends a function's stack Ä CODE_RETURN, CODE_CLOSE_UPVALUE Ä
    closes upvalues first; the abort path was the lone exception.

    A closure created inside an aborted frame that survives (held by
    a module-level static, a host callback, an observer list, ...) keeps
    upvalues whose `value` pointers still point INTO the dead fiber's
    stack. Once GC reclaims the dead fiber and DEALLOCATEs its stack,
    subsequent reads through those upvalues return whatever now lives
    at that address Ä silently wrong values at best, SIGSEGV at worst
    when the freed memory gets recycled into something whose bytes
    decode as a tagged pointer to a stale ObjUpvalue.

    Reproducer (200 fibers each capture and abort, then read back):
    before Ä 194 of 200 closures returned the wrong value
    after Ä 0 of 200 wrong

    Filed upstream as wren-lang/wren#1234.

    Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net