basecamp / basecamp/hotcell

Evaluate: the client's connect is unbounded when the listener backlog is full

Open
#20 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Ruby
Stars
23
Forks
0
Avg merge
11h 43m
Merged PRs (30d)
27

Description

Deferred for evaluation. The report is credible but untested, and the premise it attacks may still hold.

## The report

`Transport::Socket#call` (`hotcell-client/lib/hot_cell/transport.rb:25`) calls `UNIXSocket.new` before `receive` builds any deadline, so `timeout` covers the answer and not the connection. The **Accepted risk** above it prices this, on the premise that the state is "nearly unreachable": it reads the hang as needing a supervisor that lives and stops accepting, and the run loop is built so that does not happen.

The claim is that the premise is weaker than written. `Supervisor#accept_work` (`hotcell-server/lib/hot_cell/supervisor.rb:257-271`) accepts one connection per loop pass. A peer that opens connections faster than the loop drains them keeps the kernel backlog full, and a `connect` to a full `AF_UNIX` stream backlog blocks. So the hang needs a saturated backlog, not a wedged supervisor.

## Confirmed by reading

- The timeout covers the response only. `receive` is where the deadline is built.
- `accept_work` accepts one connection per pass.
- The queue-full refusal happens *after* `accept`, so it does not bound anything before admission.

## Needs a test before anyone acts

- Demonstrate that a full backlog blocks `connect` here, and for how long.
- Establish who can cause it. A deliberate flood needs a peer already in the socket's group, which is a second compromised process. **The more interesting question is whether ordinary load can do it** — if an application can outpace one-accept-per-pass during a burst, this is a capacity behaviour and not an attack, and it pins application threads at the moment the cell is least able to help.

If ordinary load cannot reach it, the accepted risk stands roughly as written and this closes.

## Remedy, if it holds

The comment already names it: `connect_nonblock` plus `wait_writable` against the deadline `receive` builds, so one absolute deadline covers the whole call.

Raised in the pre-release review and again in an adversarial review by Codex, 2026-08-19.

Contributor guide

Open the contributing guide

Research direction

Read hotcell-client/lib/hot_cell/transport.rb:25 and hotcell-server/lib/hot_cell/supervisor.rb:257-271, then build a focused test or reproduction for a full AF_UNIX backlog. Check both deliberate flooding and ordinary load. Done means establishing whether connect blocks here and deciding whether the accepted risk stands or the stated remedy is needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
backend, networking, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.