IPC stability bugs

Audit report AR-07

Reported privately in an independent security review, 2026-08-07.

Report date
2026-08-07
Kind
Design
Status on master
Present
Proposed issue state
Open

Summary

The only bound on what an incoming IPC message can contain is Cap'n Proto's default traversal limit (64 MiB of message data, nesting depth 64). libmultiprocess has no per-method limits on container lengths, capabilities, threads, callbacks or outstanding calls. The report is accurate and presents this as a design limitation, not a bug. Under the current trust model it is up to clients to be reasonable.

The report

An informational note: Cap'n Proto's traversal limit bounds how much of a message a reader will traverse in total, but application methods and capability operations have no per-method quotas for container lengths, number of capabilities, threads, callbacks or outstanding work. The report names the unbounded ThreadMap thread creation (AR-04) as the clearest consequence. Among the regression tests it suggests is connection-count exhaustion, and the "resource governance" theme runs through its recommendations. It gives no reproduction for this note.

Proposed change

None specific. The general recommendation is per-connection resource limits.

Assessment

Accurate. Connection builds its TwoPartyVatNetwork with default capnp::ReaderOptions() on both the client and server side (include/mp/proxy-io.h). Nothing in the library limits per-method resource use, and an application cannot pass its own reader options per connection.

A peer staying within the traversal limit can still make the other side allocate: a 64 MiB message can carry a large list, and repeated calls can create many server objects. That requires a client sending such requests on purpose. Under Bitcoin Core's trust model a process that can reach the IPC socket already has unauthenticated RPC access, so quotas are defense in depth against a class of client that is not supported today.

Specific limits have been proposed separately:

Status

Present on master by design. A cheap first step would be to let applications pass their own capnp::ReaderOptions when creating a connection; the rest belongs with the specific proposals above. Idea; no issue open.

Reported privately in an independent security review on 2026-08-07.