AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 27 Bitcoin

askrene: actually run children in parallel.

Public commit record

What the developer wrote

Authored by Rusty Russell

68/100 · Adequate
askrene: actually run children in parallel.

Changelog-Changed: Plugins: `askrene` now runs routing in parallel.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes the `askrene` routing plugin so that instead of waiting for each route-finding child process to finish before starting the next one, it now runs those child processes in parallel using non-blocking I/O. The change removes a synchronous "FIXME: Go async!" bottleneck and adds a new "FIXME: limit parallelism!" note. It is a performance/behavior change rather than a clear security fix, but running children in parallel can affect resource consumption, timing, and error-handling behavior.

Recommended action

Treat this as a behavior change worth monitoring rather than an immediate vulnerability. Review the new parallelism limits, ensure `askrene->children` cannot grow without bound under load, verify that `gossmap_remove_localmods()` being called before child completion does not leave the gossmap in an inconsistent state on failure paths, and confirm that the asynchronous child reaping correctly handles slow or maliciously stalled child processes.

Security signals we found

01

Concurrency introduced where none existed before: multiple router children can now be in flight simultaneously

02

New resource-exhaustion concern: explicit developer comment 'FIXME: limit parallelism!' indicates unbounded parallelism is currently allowed

03

Error-handling path changed: `gossmap_remove_localmods()` is now called before waiting for the child, which could affect consistency if a later failure path is reached while another child is still running

04

Child process lifecycle now tied to I/O connection close callbacks (`log_closed`, `reply_closed`) rather than explicit synchronous cleanup

05

No explicit bounds on number of concurrent children, memory allocated per child (`reply_buf` grows dynamically), or CPU time

Risk score

Why this scored 27/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.