fix(command): harden length-delimited + SCM IPC against panic-OOB

[FlorentinDUBOIS]

Summary

Two panic-on-malformed-IPC bugs in sozu-command-lib are reachable across the worker/master trust boundary, and one of them — the length-delimited command channel — is externally reachable through the admin unix socket. Both panicked with slice index starts at N but ends at M on attacker-controlled framing. This branch hardens the receiver and adds unit-level + end-to-end regression tests.

#	Severity	Surface	Fix
1	HIGH	command/src/channel.rs:476 — &buffer[delimiter_size()..message_len]	reject message_len < delimiter_size() and drop the bogus delimiter so the channel re-syncs
2	MEDIUM	command/src/scm_socket.rs:148-167 — received_fds[index..index+len]	validate http+tls+tcp ≤ min(MAX_FDS_OUT, fds_received) before slicing

Both bugs violate the rule stated in CLAUDE.md: "No panic on network-facing input. In parser, socket, mux, TLS, command-channel, and config paths, convert invalid traffic into … a contextual log."

Finding 1 — channel.rs slice-OOB (HIGH)

Channel::try_read_delimited_message decoded a peer-supplied usize length prefix and then sliced &buffer[delimiter_size()..message_len]. A peer that wrote a delimiter declaring message_len < delimiter_size() (e.g. 5 on a 64-bit host) bypassed the existing > max_buffer_size guard and panicked the receiver. Reachable from any local user with write perms on the admin unix socket → full-proxy DoS until restart.

Patch:

• new ChannelError::MessageLengthUnderDelimiter variant, symmetric with the existing MessageTooLarge upper-bound rejection;
• consume the bogus delimiter bytes (self.front_buf.consume(delimiter_size())) before returning, so the channel re-syncs on the peer's next valid frame instead of looping forever on the stale header.

CWE-129 (Improper Validation of Array Index) → reachable as CWE-248 (Uncaught Exception).

Finding 2 — scm_socket.rs slice-OOB (MEDIUM)

ScmSocket::receive_listeners zipped the peer-supplied ListenersCount.{http,tls,tcp} lists against a fixed [RawFd; MAX_FDS_OUT] (200 slots) without bounds-checking the declared counts. A manifest declaring more entries than MAX_FDS_OUT or more entries than the FDs that actually arrived panicked the receiver on received_fds[index..index + len], or on the trailing received_fds[index..file_descriptor_length] slice when index > file_descriptor_length.

Patch:

• validate http + tls + tcp ≤ min(MAX_FDS_OUT, fds_received) up front, with checked_add to guard against usize overflow;
• surface the mismatch as a new ScmSocketError::ListenersCountInconsistent carrying every input that contributed to the decision;
• rework the trailing tcp slice from received_fds[index..file_descriptor_length] to the symmetric received_fds[index..index + tcp_len] (identical result under the new invariant; no silent excess-FD acceptance).

Protocol / security impact

• Command channel: no wire-format change. New error path is reached on a previously-panicking input only.
• SCM channel: no wire-format change. A well-formed ListenersCount (where counts match the FD set, as produced by ScmSocket::send_listeners) is accepted identically.
• No change to TLS, H1, H2, proxy-protocol, or any front-facing protocol surface.
• No new metrics, config keys, or CLI flags. doc/configure.md unchanged.

Tests added

Unit regressions (live alongside the patched code):

• command/src/channel.rs::tests::rejects_declared_length_below_delimiter — writes a 5-byte-declared delimiter via raw Write::write_all on the underlying mio unix stream and asserts the new error variant instead of the pre-fix panic.
• command/src/scm_socket.rs::tests::rejects_listeners_count_with_more_entries_than_fds — ships a forged ListenersCount { http: 3 } with zero FDs and asserts the new error variant.

End-to-end regression (new file e2e/src/tests/command_channel_security_tests.rs, 218 lines):

• channel_short_delimiter_does_not_panic_worker spawns a real worker via Worker::start_new_worker, writes the malformed delimiter, asserts the worker thread is still alive, then sends a real SoftStop and asserts wait_for_server_stop() returns cleanly — the second assertion is the re-sync proof.
• scm_inconsistent_listeners_count_does_not_panic_server_constructor drives the real Server::try_new_from_config constructor with a forged SCM payload and pattern-matches on ServerError::ScmSocket(ListenersCountInconsistent). The match arm references the new variant, so a future revert of scm_socket.rs fails to compile — compile-time regression gate.

Sensitivity verified by reverting each fix locally:

• without the channel.rs bounds check, the e2e test panics at channel.rs:498:49 with the exact original slice index starts at 8 but ends at 5 message;
• without the scm_socket.rs guard, the e2e file fails to compile because the new enum variant is gone.

Commands run

cargo build --all-features --locked                    # green (1m12s)
cargo +nightly fmt --all -- --check                    # clean
cargo clippy --all-targets --locked -p sozu-command-lib -- -D warnings   # clean
cargo clippy -p sozu-e2e --tests -- -D warnings        # clean
cargo test -p sozu-command-lib --locked                # 94/94 pass
cargo test -p sozu-lib --locked                        # 542/542 pass
cargo test -p sozu --locked                            # 34/34 pass
cargo test -p sozu-e2e --offline command_channel_security  # 2/2 pass

Doc updates

None required — no new config keys, metrics, CLI flags, or behaviour change for well-formed traffic. CLAUDE.md's "no panic on network-facing input" rule already covers the command-channel path; this PR brings the implementation in line with that rule.

Test plan

• CI matrix (stable / beta / nightly × crypto-ring / crypto-aws-lc-rs / crypto-openssl / fips) all green
• cargo +nightly fmt --check green
• cargo test -p sozu-e2e -- command_channel_security shows 2 passing tests
• Reviewer reverts each fix(command): commit locally to confirm the e2e tests turn red (panic for channel, compile error for SCM)