fix(net): cap child-controlled sockaddr length before reading it

[dzerik]

Problem

A sandboxed child can force a multi-GiB allocation in the supervisor by passing an oversized sockaddr length. connect/sendto/sendmsg/sendmmsg take the address length straight from child-controlled args (addr_len = args[5], msg_namelen, both u32 up to 0xFFFFFFFF). The seccomp-notify trap fires at syscall entry, before the kernel's own addrlen > sizeof(sockaddr_storage) → EINVAL check, so the length reached read_child_mem uncapped and read_child_mem_vm did vec![0u8; len].

Repro (any active net interception):

int fd = socket(AF_INET, SOCK_DGRAM, 0);
sendto(fd, buf, 1, 0, &valid_sockaddr_in, 0xFFFFFFFF);

The supervisor allocates ~4 GiB for a sockaddr that is at most 128 bytes. Under default overcommit this is a repeatable transient memory-amplification; under RLIMIT_AS / overcommit_memory=2 / low RAM the Rust allocation fails and handle_alloc_error aborts the whole supervisor — a fail-open crash of the security monitor that takes down every sandbox it runs.

Every other child-controlled read is already bounded (MAX_SEND_BUF 64 MiB, MAX_CONTROL_BUF 16 KiB, iovlen 1024, vlen 256). The sockaddr length was the one uncapped read.

Fix

Clamp each of the six sockaddr reads to MAX_SOCKADDR_LEN = size_of::<sockaddr_storage>() (128). The gate only needs the family and address bytes, and the actual send is either re-run by the kernel (Continue) or performed on-behalf with our own correctly-sized sockaddr, so no legitimate call (a real sockaddr is ≤ 128 bytes) is affected.

Test

cargo build clean; full sandlock-core lib suite green (444), including the network tests.

Notes

• Found while reviewing refactor(net): restructure the network module into parse/decide/execute phases #128; this targets main directly since the bug is live there. If refactor(net): restructure the network module into parse/decide/execute phases #128 lands first, the same clamp applies to the split network/ modules (trivial rebase).
• A separate follow-up will address the AF_UNIX datagram gating asymmetry noted in the refactor(net): restructure the network module into parse/decide/execute phases #128 review — that one needs an SO_DOMAIN-gated change across sendmsg/sendmmsg/sendto and is kept out of this focused security fix.

[congwang-mk]

Good catch! Instead of silent cap, is returning Errno(EINVAL) better?

[dzerik]

Agreed — EINVAL is the better call (it's what the kernel returns for addrlen > sizeof(sockaddr_storage), and it avoids the silently-truncated read). Done in a60730c.

Factored the six sockaddr reads through one read_sockaddr helper that guards the length before the allocation and rejects an oversized one with EINVAL (a read fault still maps to EIO). The four handler-level sites propagate it directly; the two classifier helpers (unix_sendmsg_gate, mmsg_entry_named_unix_path) keep .ok()?, so an oversized length there falls through to a guarded read on the send/prescan path that surfaces EINVAL — no path allocates before the guard.

Updated the regression test accordingly: the 4 GiB addr_len sendto now expects EINVAL (22) rather than the gate result, and still asserts the supervisor survives.

[congwang-mk]

@dzerik I may misunderstood your message as I merged PR #128 before this one. Do you mind to rebase? Sorry for the inconvenience. Thanks