• src/syncterm/term.c

    From Deuc¨@VERT to Git commit to main/sbbs/master on Sun Mar 15 01:06:05 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/d5e37e7999b5adf959d31e60
    Modified Files:
    src/syncterm/term.c
    Log Message:
    Fix buffer overflows and missing NULL checks in term.c

    apc_handler(): two strcat(fn, p) calls append data from APC escape
    sequences (received from the remote BBS) into fn[MAX_PATH+1] without
    length checks. Changed to strlcat(fn, p, sizeof(fn)).

    mousedrag(): sbufsize was declared int but holds
    width * sizeof(vmem_cell) * height, which is assigned to malloc().
    On very large terminal dimensions the int multiplication can wrap,
    causing an undersized allocation. Changed sbufsize to size_t with
    an explicit (size_t) cast on the first operand. Also added a NULL
    check on the three malloc() calls Ä previously a failed allocation
    would be passed straight to vmem_gettext()/gettext() and crash.

    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Sun Mar 15 01:06:05 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/95e02a29689ac912ba72c058
    Modified Files:
    src/syncterm/term.c
    Log Message:
    Fix NULL deref, buffer overflow, and over-allocation in term.c

    NULL deref in cet_telesoftware_try_get_block() (line 1269): malloc()
    result dereferenced without NULL check. The caller already handles a
    NULL return via retry loop.

    strncat overflow in apc_handler() (line 4352): The SyncTERM:C;S APC
    handler appended a network-controlled filename to fn[MAX_PATH+1]
    using strncat, whose third argument limits source bytes, not
    destination space. A malicious server sending a long filename in the
    APC sequence overflows the stack buffer. Replace with strlcat bounded
    by sizeof(fn).

    b64_decode_alloc() over-allocation (line 3538): Operator precedence
    bug: "slen * 3 + 3 / 4 + 1" computes slen*3+0+1 (since 3/4 is 0 in
    integer division) instead of the intended base64 size. This wastes 4x
    memory on 64-bit and can wrap size_t on 32-bit. Fix to the standard
    formula (slen+3)/4*3+1.

    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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