Audit fix: F-18 — cap recv_file() at 1 GiB to prevent disk-exhaustion DoS#157
Merged
adequatelimited merged 2 commits intomasterfrom Apr 13, 2026
Merged
Audit fix: F-18 — cap recv_file() at 1 GiB to prevent disk-exhaustion DoS#157adequatelimited merged 2 commits intomasterfrom
adequatelimited merged 2 commits intomasterfrom
Conversation
recv_file() had no upper limit on total bytes received. The loop appended OP_SEND_FILE packet payloads to the output file until the peer sent a short (EOF-signalling) packet or the connection dropped. A peer that streams full-size packets forever can fill the node's disk -- remote DoS. Added MAX_RECV_FILE_BYTES (1 GiB) in types.h and a cumulative `total` counter in recv_file(). When total exceeds the cap, the loop breaks and the existing error path deletes the partial file via fclose+remove, returning VERROR. 1 GiB is well above any legitimate single-file transfer the protocol performs (tfile.dat: tens-to- hundreds of MB; block files: <= 448 MB by protocol limits). Verified with a fork-based test harness (committed as .disable per the existing convention for reference test code not wired into `make test`). The harness forks a fake peer that streams OP_SEND_FILE indefinitely; the parent calls recv_file() and confirms VERROR return plus partial-file removal. Tested with cap temporarily lowered to 16 MiB for a fast cycle; cap restored to 1 GiB before commit. Closes #92
fix(network): cap recv_file() cumulative bytes at 1 GiB
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Promotes F-18 from
audit-fixestomaster.src/network.c,src/types.h,src/test/_f18-recv-file-limit.c.disablerecv_file()at 1 GiB; fix the disk-exhaustion DoS in which a malicious peer streamsOP_SEND_FILEpackets foreverScope audit
All changes localized. The
.disabletest harness adds 212 lines of test-only code that is NOT built bymake test(the.disablesuffix excludes it from the Makefile glob, matching the existing convention:gettx-tag-resolve.c.disable,proof-checkproof.c.disable,proof-support.c.disable).Artifact sweep
Verified the diff contains NO:
return VEOKat top ofvalidate_pow())LOCAL TEST ONLY,DO NOT COMMIT,F-.. TRACE,RESTORE before commit,-ftrivial-auto-var-initmarkerssrc/tfile.c:validate_pow()starts with the originalconst word32 peach_trigger[2]declaration, unchanged.Build
make NO_CUDA=1 mochimopasses cleanly on default-Werror -Wextra -Wpedanticwith gcc-13 on Ubuntu 24.04 WSL. No-Wno-errorworkaround needed.Empirical validation (from PR #156)
Fork-based test harness (committed as
.disable) that stands up a malicious peer streaming unlimitedOP_SEND_FILEpackets and verifiesrecv_file()trips the cap. Ran with cap temporarily lowered to 16 MiB for fast cycle (restored to 1 GiB before commit):Test plan