Split into domain files and consolidate

[jserv]

This splits seccomp-dispatch.c into 6 files organized by syscall domain:
dispatch-internal.h shared inlines, externs, handler prototypes
dispatch-net.c socket/network handlers
dispatch-id.c UID/GID/groups identity handlers
dispatch-exec.c exec, mmap, mprotect, clone3
dispatch-misc.c time, pipe, iovec, links, ioctl, prctl

The main file retains infrastructure (path/shadow caching, guest memory access, FD injection), core I/O/FD/directory handlers, and the dispatch router.

Change-Id: Ic4d842671f7a4ccdc116474e761062c74d5529d5

---

Summary by cubic

Split the seccomp dispatcher into domain-specific files with a shared internal header to simplify maintenance and speed up incremental builds. The main dispatcher now focuses on infrastructure (path/shadow caching, guest memory access, FD injection), core I/O/FD/directory handlers, and routing.

• Refactors
  • Moved syscall handlers into dispatch-net.c (sockets), dispatch-id.c (UID/GID/groups), dispatch-exec.c (exec/mmap/mprotect/clone3), and dispatch-misc.c (time, pipe, iovec, links, ioctl, prctl), with shared helpers in dispatch-internal.h.
  • Updated mk/features.mk to build the new units and expanded scripts/pre-commit.hook cppcheck suppressions.

^{Written for commit 46f33be. Summary will update on new commits.}

[cubic-dev-ai]

5 issues found across 21 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/dispatch-misc.c">

<violation number="1" location="src/dispatch-misc.c:184">
P2: FD leak in tracee: if `request_addfd` succeeds for `host_pipefd[0]` but fails for `host_pipefd[1]`, the already-injected `tracee_fd0` is never closed in the tracee. The tracee gets an error return from `pipe2` and is unaware of the leaked FD. Consider closing `tracee_fd0` in the tracee (e.g., via an `addfd` to overwrite it, or noting this as a known limitation).</violation>

<violation number="2" location="src/dispatch-misc.c:519">
P2: `iovcnt_raw == 0` should return 0 (success), not `EINVAL`. Linux `readv`/`writev` only return `EINVAL` when `iovcnt` is negative or exceeds `UIO_MAXIOV`; a zero count is a valid no-op that returns 0.</violation>
</file>

<file name="scripts/pre-commit.hook">

<violation number="1" location="scripts/pre-commit.hook:186">
P2: Global suppression of `knownConditionTrueFalse` masks dead-code/logic diagnostics that this hook is supposed to catch.</violation>

<violation number="2" location="scripts/pre-commit.hook:534">
P2: Multi-line printf/fprintf/snprintf calls are now excluded from non-literal format checks, so unsafe format strings can bypass this security scan.</violation>
</file>

<file name="src/dispatch-net.c">

<violation number="1" location="src/dispatch-net.c:575">
P1: `forward_recvmsg` writes back `msg_namelen` but never zeroes `msg_controllen` or `msg_flags` in the tracee's msghdr. Since the underlying implementation uses `recvfrom` (not `recvmsg`), no control data is received, but the tracee still sees its original `msg_controllen` value — causing `CMSG_FIRSTHDR()` to parse uninitialised memory from the `msg_control` buffer. Zero both `msg_controllen` and `msg_flags` after the write-back of `msg_namelen`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P1: forward_recvmsg writes back msg_namelen but never zeroes msg_controllen or msg_flags in the tracee's msghdr. Since the underlying implementation uses recvfrom (not recvmsg), no control data is received, but the tracee still sees its original msg_controllen value — causing CMSG_FIRSTHDR() to parse uninitialised memory from the msg_control buffer. Zero both msg_controllen and msg_flags after the write-back of msg_namelen.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/dispatch-net.c, line 575:

<comment>`forward_recvmsg` writes back `msg_namelen` but never zeroes `msg_controllen` or `msg_flags` in the tracee's msghdr. Since the underlying implementation uses `recvfrom` (not `recvmsg`), no control data is received, but the tracee still sees its original `msg_controllen` value — causing `CMSG_FIRSTHDR()` to parse uninitialised memory from the `msg_control` buffer. Zero both `msg_controllen` and `msg_flags` after the write-back of `msg_namelen`.</comment>

<file context>
@@ -0,0 +1,581 @@
+
+    /* Update msg_namelen in the msghdr. */
+    int nwrc =
+        guest_mem_write(ctx, pid, msg_ptr + 8 /* offset of msg_namelen */,
+                        &out_addrlen, sizeof(out_addrlen));
+    if (nwrc < 0)
</file context>

[cubic-dev-ai]

P2: FD leak in tracee: if request_addfd succeeds for host_pipefd[0] but fails for host_pipefd[1], the already-injected tracee_fd0 is never closed in the tracee. The tracee gets an error return from pipe2 and is unaware of the leaked FD. Consider closing tracee_fd0 in the tracee (e.g., via an addfd to overwrite it, or noting this as a known limitation).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/dispatch-misc.c, line 184:

<comment>FD leak in tracee: if `request_addfd` succeeds for `host_pipefd[0]` but fails for `host_pipefd[1]`, the already-injected `tracee_fd0` is never closed in the tracee. The tracee gets an error return from `pipe2` and is unaware of the leaked FD. Consider closing `tracee_fd0` in the tracee (e.g., via an `addfd` to overwrite it, or noting this as a known limitation).</comment>

<file context>
@@ -0,0 +1,914 @@
+        return kbox_dispatch_errno(-tracee_fd0);
+    }
+
+    int tracee_fd1 = request_addfd(ctx, req, host_pipefd[1], cloexec_flag);
+    if (tracee_fd1 < 0) {
+        close(host_pipefd[0]);
</file context>