fix(cypher): bound UNWIND literal-list buffer to prevent stack overflow

[SEPURI-SAI-KRISHNA]

What does this PR do?

Fixes a stack out-of-bounds write (CWE-787) in the Cypher UNWIND literal-list
parser (parse_unwind_clause, src/cypher/cypher.c).

When assembling a literal list into the fixed 2 KB stack buffer
char buf[CBM_SZ_2K], the code advances the write cursor by the return value of
snprintf:

blen += snprintf(buf + blen, sizeof(buf) - blen, "\"%s\"", peek(p)->text);

snprintf returns the number of bytes it would have written, so a single
oversized element pushes blen past sizeof(buf). The trailing writes are then
unguarded:

buf[blen++] = ']';
buf[blen] = '\0';

and on multi-element lists the next iteration's sizeof(buf) - blen underflows
to a huge size_t, letting snprintf write far past the buffer.

The query string is agent-controlled through the MCP query tool, and Cypher
string literals lex up to CBM_SZ_4K - 1 (4095) chars with no length cap before
parsing, so UNWIND ["<~3000 chars>"] AS x MATCH (n) RETURN n reaches the
overflow.

Reproduced first (UBSan, before the fix):

src/cypher/cypher.c:1855:12: runtime error: index 3002 out of bounds for type 'char [2048]'
src/cypher/cypher.c:1855:21: runtime error: store to address 0x... with insufficient space for an object of type 'char'
src/cypher/cypher.c:1856:12: runtime error: index 3003 out of bounds for type 'char [2048]'

The fix clamps blen after every snprintf and guards the raw
buf[blen++] stores — the same pattern already used by the sibling function
format_collect_list(), which builds an identical JSON array into a
CBM_SZ_2K buffer and was already hardened. After the fix all 161 cypher tests
pass with zero sanitizer errors.

Two regression tests are added (both fail under UBSan without the fix):

• cypher_parse_unwind_oversized_literal_no_overflow — single oversized element
• cypher_parse_unwind_many_elements_no_overflow — many elements accumulating past 2 KB

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[DeusData]

Thanks for the reproduce-first memory-safety fix. Triage is complete: this is a high-priority 0.9.1-rc Cypher stability/security item. Exact-head review at d0457f2ba95a521fb53e433394aaa7a511cec3ee found the change scoped to the parser and sanitizer regressions, with no dependency, workflow, installer, network, or vendored-code changes. It remains in the maintainer review queue; this triage pass does not merge PRs.

[DeusData]

Thanks for this, and sorry for the slow first response. Queued for review.

MERGEABLE with all 20 checks green — nothing blocking on your side.

Useful context you may not have: #1192 reports that UNWIND is parsed but never executed at all. I confirmed that on main — q->unwind_expr and q->unwind_alias are assigned during parsing and thereafter only freed, with no executor reads. Your PR bounds the literal-list buffer on the parse path, which is a genuine memory-safety fix and stands on its own merits regardless of how the executor gap is eventually closed. Just flagging the adjacency so neither of us is surprised.

[DeusData]

Thank you — this is a real, agent-reachable stack overflow and the fix is the right shape.

Verified independently rather than taking the description on trust: the parser advances blen by snprintf's would-be length into a 2 KB buffer while string literals lex up to 4095 bytes, then writes the closing bracket unguarded — and with multiple elements sizeof(buf) - blen underflows into a huge size_t. Reachable through the MCP query tool, which makes it worth fixing carefully. I traced the corrected control flow: every write stays within cap - 1 and NUL-termination is preserved on each path. It matches the already-hardened format_collect_list, so the codebase now treats both list builders the same way.

One consequence worth stating out loud for whoever reads this later: an oversized literal is now silently truncated, so unwind_expr may lack its closing bracket. That is the safe behaviour and consistent with the sibling function; if we ever decide a parse error is better, that is a deliberate follow-up rather than something this PR got wrong.

Merging.