fix(serve): bound request-line size in handle_connection to prevent local DoS - #209

…ocal DoS

`handle_connection` in `tgrep-cli/src/serve.rs` used
`BufReader::read_line(&mut String)` with no upper bound on how much data
it would buffer before seeing a newline. A local, unauthenticated client
that connects to the server's TCP port (discoverable via the
world-readable `serve.json`) and streams bytes without ever sending `\n`
can grow that `String` without limit, exhausting process memory
(observed: 11MB -> 2.7GB in ~2s in local testing).

This is tracked as MSRC case #162882 / ICM 31000000761603
(CWE-770: Allocation of Resources Without Limits or Throttling,
Severity: None / Security Impact: Defense in Depth / Resolution:
Informational, Plan of Action due 2026-10-25).

Notably, the managed shared-daemon protocol in
`tgrep-cli/src/serve/shared/protocol.rs` already enforces exactly this
kind of bound via its own `read_line(stream, limit)` helper, reusing
`tgrep_core::managed::MAX_REQUEST_BYTES` (1MB). The primary
`tgrep serve` connection path predates that protocol and was never
updated to match -- this fix brings it in line.

Fix: introduce `read_bounded_line`, a drop-in replacement for the
unbounded `BufReader::read_line` call, capped at the same
`MAX_REQUEST_BYTES` limit used elsewhere in the codebase. Once a peer
exceeds the limit without sending a newline (or disconnects mid-line),
the connection is dropped with an error instead of being read
indefinitely.

Tests added (`serve::read_bounded_line_tests`):
- normal line round-trip
- clean EOF handling
- multiple lines on one stream
- regression test: oversized line with no newline is rejected (the
  exact DoS pattern from the report)
- boundary test: a line exactly at the limit is still accepted
  (bound is inclusive, not off-by-one)
- a line missing its newline but under the limit is still rejected
  (no silent truncation/partial-read as a "complete" request)

All 345 existing tgrep-cli tests continue to pass; `cargo fmt --check`
is clean.

Co-authored-by: Copilot <[email protected]>

…decoding

Per PR review from Copilot: String::from_utf8_lossy() silently replaces
invalid UTF-8 bytes with U+FFFD, which would let JSON parsing succeed
against a line the attacker (or a bug) corrupted -- e.g. a malformed
params.pattern silently becomes a different pattern instead of being
rejected. Switch to String::from_utf8(bytes)?, which fails the request
the same way the original read_line(&mut String) implicitly guaranteed
(std strings are always valid UTF-8).

Added a regression test with an invalid UTF-8 byte embedded in an
otherwise well-formed, newline-terminated JSON-RPC request line.

346 tgrep-cli tests pass (was 345); cargo fmt --check clean.

Co-authored-by: Copilot <[email protected]>