Skip to content

Audit fixes batch 7: reject oversized peer list responses#144

Merged
adequatelimited merged 2 commits intomasterfrom
audit-fixes
Apr 6, 2026
Merged

Audit fixes batch 7: reject oversized peer list responses#144
adequatelimited merged 2 commits intomasterfrom
audit-fixes

Conversation

@adequatelimited
Copy link
Copy Markdown
Collaborator

Summary

Seventh batch of audit remediation. One fix.

Changes

  • [F-29] network.c -- Reject oversized peer list responses in get_ipl(). A peer responding to OP_GET_IPL could include up to 65535 bytes of IP data. Added a bounds check rejecting responses where len exceeds RPLISTLEN * sizeof(word32) (256 bytes = 64 IPs) -- the maximum a legitimate node would ever send. Added TODO noting that received peer IPs should be treated as unverified candidates. (Closes [F-29] HIGH: get_ipl() trusts any valid packet — no OP_SEND_IPL or length validation #107)

Testing

  • Clean build with -Wall -Werror -Wextra -Wpedantic (GCC 13)
  • 1 file changed, 8 insertions

Closes #107

A peer responding to OP_GET_IPL could send up to 65535 bytes of
IP data (word16 len field). The consumer loop in scan_quorum()
is bounded by netplistidx < 1024, but the excess data still
causes unnecessary iteration. Added a check rejecting responses
where len exceeds RPLISTLEN * sizeof(word32) — the maximum a
legitimate node would ever send.

Added TODO noting that received peer IPs should be treated as
unverified candidates rather than trusted immediately.
[F-29] fix(network): reject oversized peer list responses in get_ipl()
@adequatelimited adequatelimited merged commit 8fdb128 into master Apr 6, 2026
4 of 5 checks passed
adequatelimited added a commit that referenced this pull request Apr 13, 2026
Audit fixes batch 7: reject oversized peer list responses
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[F-29] HIGH: get_ipl() trusts any valid packet — no OP_SEND_IPL or length validation

1 participant