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

peer: enforce onion message rate limits at ingress

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

95/100 · Strong
peer: enforce onion message rate limits at ingress

This commit plumbs the combined IngressLimiter (per-peer + global)
through peer.Config and consults it from the readHandler's
*lnwire.OnionMessage case. The decision is factored into a small
allowOnionMessage helper so that the ingress policy is directly
unit-testable without standing up a full Brontide harness. Per-peer is
checked first inside the IngressLimiter: if we consulted the global
limiter first, a peer whose own bucket was already empty would still
get to burn a global token on each attempt, letting a single hostile
peer drain the shared budget and starve legitimate peers.

peer.Config carries a single OnionLimiter field of IngressLimiter type;
the brontide readHandler calls a single AllowN per incoming onion
message and dispatches on sentinel errors via errors.Is for the
first-drop log path. Nil limiter values are treated as "disabled"
throughout, which both preserves the pre-change behavior when onion
messaging is entirely turned off and keeps the brontide test harness
from needing to construct real limiters. Per-peer bucket state is
retained across disconnect at the IngressLimiter layer so a peer
cannot cycle the connection to reset its per-peer allowance.

OnionMessage also gains a WireSize method that computes the
on-the-wire size directly from the in-memory fields (no round-trip
through Encode) so the hot ingress path can charge the right number of
byte tokens without paying for a full serialization.

The accompanying unit tests cover the nil/disabled path, the
per-peer-rejects-first ordering invariant (asserting the global
limiter is not consulted when the per-peer bucket is empty), the
global rejection path, per-peer isolation across distinct pubkeys, and
a small concurrent stress test that asserts every attempt is accounted
for as either accepted or dropped and that the total accepted count
equals the configured burst under -race. A property-based rapid test
on WireSize guards against silent divergence from WriteMessage if the
OnionMessage wire format ever gains a TLV extension.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds rate limiting for incoming onion messages in the LND Lightning node. Before this change, a single peer could potentially flood the node with onion messages, consuming shared resources and possibly disrupting service for others. The fix enforces per-peer and global byte-based limits before processing each onion message, and keeps per-peer limits even if the peer reconnects. It is a hardening change rather than a fix for a known active exploit.

Recommended action

No immediate action required; this is a defensive hardening patch. Operators should ensure onion message rate limiting is enabled in their LND configuration and monitor logs for 'onion message rate limiter engaged' messages, which indicate a peer or the global budget is being exhausted.

Security signals we found

01

Adds ingress rate limiting for onion messages to mitigate resource exhaustion

02

Per-peer bucket checked before global bucket to prevent a single hostile peer from draining shared budget

03

Per-peer rate-limit state retained across disconnect to prevent bucket reset by reconnecting

04

Nil limiter treated as disabled to preserve backward compatibility and test behavior

05

New WireSize method avoids expensive serialization on hot ingress path

Risk score

Why this scored 52/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.