fix(shuf): cap range and repeat output allocation

[chaliy]

What

Fix shuf so attacker-controlled numeric ranges and repeat counts cannot force unbounded in-process allocation.

Why

shuf -i LO-HI -n N materialized the full range before applying -n, and shuf -r -n N collected all repeated output before interpreter stdout truncation. Huge u64 inputs could exhaust CPU or memory.

How

• Represent numeric ranges separately from materialized line input.
• Sample bounded range output directly without collecting the full range.
• Check repeat/range output against ExecutionLimits before allocation.
• Add regression tests for huge range -n 1 and repeat output caps.
• Document the threat as TM-DOS-090.

Risk

• Low
• shuf now returns an explicit error when requested output exceeds the execution output limit instead of relying on post-command truncation.

Checklist

• Tests added or updated
• Backward compatibility considered

Validation:

• cargo fmt --check
• CARGO_INCREMENTAL=0 cargo clippy --all-targets -- -D warnings
• CARGO_INCREMENTAL=0 cargo test
• CARGO_INCREMENTAL=0 just vet
• CLI smoke: huge range -n 1 returns one line
• CLI smoke: oversized repeat exits 1 with output too large

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	0616dab	Commit Preview URL	May 08 2026, 08:07 PM