d70d41c1-e1cf-40ba-9026-644040a7f8ea

In src/builtins/numbers.rs, the range and range_step builtins allocate with Vec::with_capacity before enforce_limit runs. Confirm whether that ordering is actually reachable with attacker-controlled bounds, and quantify the largest allocation a caller could request. Cite exact lines. Do not change any files.

I'll look at the actual code.

## Confirmed: the ordering is reachable, and the guard is post-hoc by construction **The code path** — `src/builtins/numbers.rs`: - `range`: bounds parsed at `numbers.rs:88-89`, element count computed at `numbers.rs:103-107`, allocation at **`numbers.rs:109`** (`Vec::with_capacity(num_elements)`), first `enforce_limit()` at **`numbers.rs:116`** — inside the loop, *after* the allocation and after the first `push`. - `range_step`: same shape — count at `numbers.rs:147-151`, allocation at **`numbers.rs:153`**, first `enforce_limit()` at **`numbers.rs:160`**. There is no bound on `num_elements` between the arithmetic and the `with_capacity` in either function. **Reachability.** Both are registered builtins (`numbers.rs:28-29`) and take their bounds straight from evaluated arguments via `ensure_numeric` (`numbers.rs:88-89`, `127-129`), so `numbers.range(input.lo, input.hi)` puts the count fully under caller control. Nothing in the non-`strict` path narrows it either: `strict` only rejects non-integers (`numbers.rs:91-101`) and, for `range_step`, non-positive steps (`numbers.rs:143-145`). Integer bounds of any magnitude pass both modes. **Quantifying the request.** The only ceiling is `Number::as_i64` returning `Some` at `numbers.rs:103` / `147`, so the span `v2 - v1` is capped at `i64::MAX`. Worst case for `range` (`numbers.rs:104`): `num_elements = i64::MAX as usize + 1 = 2^63 = 9,223,372,036,854,775,808`. `Value` is 24 bytes on 64-bit (`src/value/mod.rs:60-85`; the `Number(Number)` variant is 16 bytes — `src/number.rs:41-46` — plus `Value`'s own discriminant), giving a requested ~192 EiB. That exceeds `isize::MAX`, so `with_capacity` panics with `capacity overflow` rather than calling the allocator. The largest request that actually reaches the allocator is `isize::MAX / 24 ≈ 3.84e17` elements (~8 EiB), which fails and hits `handle_alloc_error` → non-unwinding abort. `range_step` at `numbers.rs:148-149` reaches the same magnitudes with `step = 1`. **Why the guard doesn't help even when it fires.** `enforce_limit` (`src/builtins/utils.rs:18-20`) resolves to a `const fn` returning `Ok(())` unless `allocator-memory-limits` is enabled (`src/utils/limits/mod.rs:41-57`), and that feature is *not* in `default` (`Cargo.toml:28`, `57-78`) — in a stock build these calls compile away entirely. With the feature on, it still returns `Ok` unless a global limit was set (`src/utils/limits/memory.rs:168-174`), and it is throttled by a 16-iteration stride / 32 KiB pending-delta watermark (`memory.rs:12-15`, `180-190`). Most importantly it reads `stats.allocated` *after* the fact (`memory.rs:147-156`), so a single oversized `with_capacity` is by definition unobservable to it until the allocation has already succeeded or killed the process. **Practical severity.** The realistic outcomes are a `capacity overflow` panic or an allocation-failure abort, not a silent limit bypass: for mid-range counts the allocation is uninitialized, so mimalloc maps address space the loop then touches gradually, and `enforce_limit` does catch that growth once a limit is configured. The release profile has no `panic = "abort"` and no overflow checks (`Cargo.toml:163-166`), so the panic unwinds — which is a crash rather than an error at any FFI boundary that can't unwind. **Two adjacent defects in the same arithmetic, worth noting since they share the inputs:** - `numbers.rs:148-149` divides by `incr` with no zero check on the non-`strict` path (`strict` guards it only at `143-145`) — `numbers.range_step(0, 10, 0)` in non-strict mode divides by zero. - `numbers.rs:105` (`(-v + 1)`) and `numbers.rs:149` (`-v / incr`) negate an `i64` that can be `i64::MIN`; in release this wraps and yields a near-`2^63` count, in debug it panics. No files were modified.