[rust] use saturating arithmetic in DNS record length checks

[winstoncrooker]

While reading through src/rust/api/dns.rs I noticed the bounds checks added in #6311 use unchecked addition between an attacker-supplied length (parsed via usize::from_str_radix from a hex token in the DNS record) and a small offset. With -Cdebug-assertions=n in release builds (per .bazelrc), a length value of usize::MAX makes length + offset wrap to a small integer, the > input.len() check passes, and the subsequent slice/index panics — the exact behavior the test commentary above the malformed-input block says we want to avoid ("these previously caused panics (index out of bounds) which would abort the process via CXX. They must return Err, not panic.").

The fix is one token per check site: length + offset → length.saturating_add(offset). Saturated overflow at usize::MAX is always greater than data.len(), so the existing Err branch fires.

Sites changed

Function	Line	Length field
parse_replacement	~98	hex frame length
parse_caa_record	~170	prefix_length
parse_naptr_record	~247	flag_length
parse_naptr_record	~256	service_length
parse_naptr_record	~265	regexp_length

Tests

Five new tests in dns.rs::tests, mirroring the existing test_parse_*_too_short_* / _truncated_at_* cases but with FFFFFFFFFFFFFFFF (or its decimal form for CAA) as the length token:

• test_parse_replacement_length_overflow
• test_parse_caa_record_prefix_length_overflow
• test_parse_naptr_record_flag_length_overflow
• test_parse_naptr_record_service_length_overflow
• test_parse_naptr_record_regexp_length_overflow

Each one panics on main and passes with this patch. I ran them in a standalone Cargo crate that mirrors the function bodies (the workerd build is bazel-only, but the math is identical in isolation); CI will run the in-tree versions via bazel test //src/rust/....

Reachability note

The whole-process impact is mitigated by jsg::catch_panic wrapping #[jsg_method] calls — a slice panic in parse_replacement is caught and surfaces as throw_internal_error + terminate_execution() on the calling isolate, not a workerd-wide abort. So in practice this is a per-request failure on Workers that call dns.resolveNaptr / dns.resolveCaa with attacker-influenced hostnames, not a tenant-isolation bug. Still seems worth fixing both because the test commentary explicitly forbids panicking here and because future callers outside the jsg catch boundary would lose that protection.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[winstoncrooker]

I have read the CLA Document and I hereby sign the CLA