Skip to content

Pong.servers has no maximum-entry contract, enabling unbounded client-side memory allocation #25

Description

@bibonix

pong.proto declares servers as an unbounded repeated field (repeated Peer servers = 13). A compromised or malicious Node can return a Pong carrying an arbitrarily large peer list, forcing the client to allocate an unbounded number of Peer objects before any application-layer size check can run. The client iterates over every Peer to pick a fallback exit, so a list of a few million entries also causes CPU exhaustion in addition to the memory pressure.

The equivalent inbound risk — Ping.canaries carrying an unbounded number of probe-failure counters — is tracked in issue #23. This is the outbound counterpart: the Node controls the response, so a client-side length check cannot prevent allocation of the initial list.

The vulnerable declaration is in pong.proto, field 13:

repeated Peer servers = 13;

The fix is to document an explicit upper bound in the field comment (e.g. "// max 256 entries; clients must reject a Pong carrying more") and enforce it in every deserializer, matching the approach that issue #23 will apply to Ping.canaries.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions