fix(security): raise OBE-10735 array-index cap from 32,768 to 2^20

[JuanMantica45]

Context

Split out from #7 to unblock that PR's merge on an unresolved review disagreement, without holding up the panic/OOM fixes it contains.

On #7, ajayshekar-s1 requested changes, arguing the cap on array-index assignment (.foo[N] = value) introduced for OBE-10735 — originally 32,768 in either direction — should be removed outright, since there could be a legitimate use case for indexing beyond that.

I pushed back on removing the cap entirely: OBE-10735 was a real, exploitable OOM. Before that fix, an event-controlled index (.foo[40000000] = 1, where the index comes from untrusted event data or an operator-authored VRL program) triggered an unbounded Vec::with_capacity(index + 1) allocation and null-padding loop — attacker-controlled memory exhaustion. Removing the cap reopens that vulnerability outright. But "the cap might be too conservative for real use cases" is a fair, separate concern from "the cap shouldn't exist," so this PR raises it instead of removing it.

This PR is now self-contained against main — it introduces the array-index cap directly at its final value (2^20) rather than depending on #7's intermediate 32,768 version, so this diff isn't entangled with #7's other 8, unrelated panic fixes. It also carries the isize::MIN overflow fix (unsigned_abs() instead of (-index) as usize, since negating isize::MIN overflows) that jsbalis1 found in review — that fix was pulled back out of #7 and lives here now, alongside the cap raise, since both touch the same capacity-calculation code.

What changed

• New MAX_ARRAY_INDEX constant in src/value/value/crud/mod.rs, set to 1_048_576 (2^20). insert_value rejects (and logs a warning for) any array-index write outside ±MAX_ARRAY_INDEX.
• src/value/value/crud/insert.rs's preallocation capacity calc uses the same shared constant, and index.unsigned_abs() instead of (-index) as usize for the negative case.
• New regression fixture lib/tests/tests/issues/obe_10735_array_index_cap.vrl exercising the cap boundary.
• Unit tests for: rejecting an index beyond the cap (positive and negative), accepting an index at the cap boundary, and not panicking on isize::MIN.

Why 2^20 specifically

std::mem::size_of::<Value>() is 40 bytes (checked directly on this branch). That makes the worst-case single-allocation cost of one indexed write:

Cap	Elements	Worst-case allocation
Unbounded (pre-fix)	unbounded	unbounded — the original OBE-10735 vulnerability
32,768 (original fix)	32,769	~1.3 MB
2^20 (this PR)	1,048,577	~42 MB

2^20 gives 32x more headroom than the original cap — enough that it's very unlikely to reject a legitimate pipeline's array usage — while keeping the worst case for a single indexed write bounded in the tens-of-MB range rather than unbounded. It's still a fixed, hardcoded ceiling, not user-configurable — if a concrete use case surfaces that needs more than this, that's a separate conversation with real data behind it, not a reason to remove the guardrail speculatively.

Note on VRL-level error surfacing

The out-of-range write currently no-ops silently (with a warn! log added here for observability) rather than returning a VRL runtime error. Making it a real error requires threading a Result through ValueCollection::insert_value, crud::insert, and the public Value::insert API, and compiler::expression::assignment::Target::insert currently discards the insert result outright — VRL array-index assignment is architecturally infallible today. That's a real, separate feature, tracked as a follow-up rather than bundled here.

Test plan

• cargo test --lib against main: 1717 passed, 0 failed
• cargo run in lib/tests (the .vrl fixture runner): obe 10735 array index cap ... OK

🤖 Generated with Claude Code