Summary

handler.handleBatch sizes its WaitGroup with wg.Add(len(msgs)) but spawns only len(calls) goroutines (one per actual call). Whenever a batch contains any message that handleResponses filters out of calls, the counter can never reach zero: wg.Wait() blocks forever and the batch's call-processing goroutine hangs. That goroutine holds callWG (via startCallProc's defer h.callWG.Done()), so handler.close's h.callWG.Wait() hangs with it, leaking the goroutine(s) plus the connection for every such request. sync.WaitGroup.Wait ignores context cancellation, so it survives client disconnect — an unauthenticated remote DoS on exposed RPC endpoints.

Pre-existing; not introduced by #22338. Filing to track the fix (promised as a follow-up during that review) and its backports.

Root cause

// rpc/handler.go, handleBatch
wg := sync.WaitGroup{}
wg.Add(len(msgs))        // counts ALL messages
for i := range calls {   // but only len(calls) goroutines are spawned
    boundedConcurrency <- struct{}{}
    go func(i int) {
        defer func() { wg.Done(); <-boundedConcurrency }()
        ...
    }(i)
}
wg.Wait()                // never returns when len(calls) < len(msgs)

handleResponses drops two message categories from calls:

1. Response-shaped messages — msg.isResponse() (has result/error, no method).
2. Subscription notifications — a notification whose method ends in _subscription (notificationMethodSuffix), which is routed to handleSubscriptionResult and continued.

Any batch mixing at least one real call with at least one message of either category gives len(calls) < len(msgs) → permanent hang.

Reproduction

A single unauthenticated HTTP request is enough:

[{"jsonrpc":"2.0","id":1,"method":"eth_chainId"},{"jsonrpc":"2.0","id":2,"result":"0x1"}]

len(msgs) == 2, len(calls) == 1 (the second entry is response-shaped and dropped) → wg.Add(2) against a single wg.Done() → wg.Wait() never returns. The connection's call goroutine and the connection itself leak; repeating the request exhausts server resources.

Impact

• Unauthenticated remote DoS against the HTTP/WS JSON-RPC endpoint when it is reachable by untrusted clients (e.g. behind a proxy, as in Panic (SIGSEGV / nil pointer) in gzipResponseWriter.Flush when serving a gzipped batch RPC request #22334).
• Per malicious request: leaks the batch call goroutine, blocks handler.close (which waits on callWG), and holds the connection open indefinitely. Survives client disconnect — WaitGroup.Wait is not context-aware.

Affected branches

Present identically on every maintained line (same wg.Add(len(msgs)) / for i := range calls shape), so each needs its own backport:

Suggested fix

Count the goroutines actually spawned, not the incoming messages:

wg.Add(len(calls))

Please land it with a regression test (TDD): send a mixed batch (a real call plus a response-shaped message, and a real call plus a _subscription notification) and assert the request returns instead of hanging.

Provenance

Flagged during review of #22338 by @yperbasis ("Point 2"), and independently by Copilot as a low-confidence note — it is real. @lupin012 indicated it would be handled in a separate PR; this issue gives that follow-up a home and a place to track backports across release lines. The gzip-race cherry-pick to release/3.5 that surfaced this is #22383.