[High][Security/DoS] Message receiver allows unbounded allocation and retention from untrusted input #30
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The message subsystem currently lets remote peers drive memory growth in several ways:
INITcan force allocation based on an untrusted declared message length.VecDeque.Why this matters
This creates a practical denial-of-service surface on any node that accepts messages.
An attacker does not need to complete valid messages to cause damage. They can repeatedly send large
INITmetadata, incomplete streams, or just generate completed messages faster than the application drains them.Evidence
Untrusted allocation based on declared message length:
mycelium/src/message.rs:420-421Pending inbound state is inserted here:
mycelium/src/message.rs:432Pending state is only removed on
DONE/ABORThandling here:mycelium/src/message.rs:654mycelium/src/message.rs:675Completed messages are retained in an unbounded queue defined here:
mycelium/src/message.rs:127-135Completed messages are appended in multiple paths, for example:
mycelium/src/message.rs:631-633mycelium/src/message.rs:649-651Expected behavior
The subsystem should enforce bounded memory usage for hostile or slow-consumer scenarios.
Actual behavior
The implementation has no obvious hard cap or expiry for inbound message state.
Suggested fix
complete_msgesand choose a policy for overflow.Risk
High. This is a classic remote memory pressure / DoS vector in a network-facing subsystem.