fix(store): clamp ADR render cursor to prevent stack overflow

[SEPURI-SAI-KRISHNA]

What does this PR do?

Fixes a stack out-of-bounds write (CWE-787) in adr_render_section
(src/store/store.c), the helper cbm_adr_render uses to concatenate ADR
sections into a fixed 16 KB stack buffer (buf[ST_MAX_DEGREE * ST_GROWTH]).

The cursor was advanced by the return value of snprintf:

pos += snprintf(buf + pos, buf_sz - pos, "\n\n");
pos += snprintf(buf + pos, buf_sz - pos, "## %s\n%s", key, value);

snprintf returns the number of bytes it would have written, so once the
accumulated sections exceed buf_sz, pos moves past the end. On the next
section buf + pos points past the buffer and buf_sz - pos (an int
subtraction) goes negative, converting to a huge size_t — so snprintf
writes out of bounds.

The fix clamps pos into [0, buf_sz - 1] after every write, so each
snprintf receives a positive size and the returned cursor never escapes the
buffer. This mirrors the clamping already done by http_appendf in
src/ui/http_server.c and the sibling accumulators in store.c
(search_build_exclude_labels, bfs_build_types_clause).

Reproduced first (ASan, before the fix):

==ERROR: AddressSanitizer: stack-buffer-overflow ... WRITE of size 3
    #3 adr_render_section src/store/store.c:7008
    #4 cbm_adr_render     src/store/store.c:7057
    #5 test_adr_render_oversized_sections_no_overflow tests/test_store_arch.c
SUMMARY: AddressSanitizer: stack-buffer-overflow ... in vsnprintf

After the fix the full store_arch suite (53 tests) passes with no sanitizer
errors.

Adds a regression test adr_render_oversized_sections_no_overflow that sizes
three sections so the cursor lands exactly buf_sz + 8 after the second
section — the third section then performs the first out-of-bounds write right
at the buffer tail (ASan redzone), making the failure deterministic.

Note on scope

cbm_adr_render / cbm_store_adr_update_sections are exported in store.h
and exercised by the test suite, but currently have no production caller — the
manage_adr MCP tool and the UI /api/adr endpoint both persist raw content
via cbm_store_adr_store. So this is a latent defect in exported API rather
than a live remote overflow; the fix hardens the renderer before anything
wires up the section-merge path.

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 hardening fix. Triage is complete: this is a high-priority 0.9.1-rc stability/security item. Exact-head review at 13d523de484381cdbaff6fa52549836983cc88f0 found the change scoped to the exported ADR renderer and its deterministic ASan regression, with no new public surface or supply-chain changes. It remains in the maintainer review queue; this triage pass does not merge PRs.

[DeusData]

Thanks, and sorry for the wait. Queued for review.

MERGEABLE, all 20 checks green, +71/-3 across two files — nothing blocking on your side.

Clamping a render cursor to prevent stack overflow is exactly the kind of bounded, provable fix that is easy to review and easy to trust.

[DeusData]

Thank you — merged.

I verified the overflow rather than trusting the writeup: in adr_render_section an unclamped cursor makes buf_sz - pos negative, which becomes an enormous size_t at the snprintf call. Your clamp keeps the returned cursor at buf_sz - 1 and the NUL-termination invariant holds through truncation. I also re-derived your test's arithmetic by hand — the third append genuinely lands past the buffer into the ASan redzone pre-fix, so the test binds deterministically rather than probabilistically.

One thing I want to record accurately, because it affects how urgently anyone should backport this: cbm_adr_render and cbm_store_adr_update_sections currently have no production callers — I grepped src/ to confirm. So this hardens a latent API rather than closing a live remote overflow. That makes it no less worth merging: the next caller would have inherited the bug, and now they will not.

Appreciated.