Mirrored from filpgf.io — ProPGF Batch 3 (Karma program 1479, application 6a23ce6a34bfda5752c195f0, status: pending). Contact details redacted; canonical application lives on filpgf.io. 1.1 Project Name Filecoin Forest Security Fuzzing and Audit Infrastructure 1.2 Project Github https://github.com/robustfengbin/forest-fuzz-poc 1.4 Team Lead/Point of Contact Robust — Independent Security Engineer; Lead of the Zebra node coverage-guided fuzzing project (accepted Zcash Community Grant #234). GitHub: https://github.com/robustfengbin. Preferred channel: Telegram @robustfen 1.5 Category [ "Core Infrastructure" ] 1.6 Open Source Status Fully Open Source 2.1 Project Summary A 6-month coverage-guided fuzzing and hardening program for ChainSafe Forest. Forest has conventional tests and meaningful `quickcheck` property tests, but our review at commit `94cc463` found **no systematic `cargo-fuzz` layer, no persistent minimized corpus, and no CI/nightly fuzzing workflow** — a green field. We build and run oracle-driven fuzz targets across Forest's untrusted input surfaces, starting with gossip block/message and CAR/snapshot parsing, then header/tipset, chain-exchange/Hello, CID/CBOR, RPC/Eth-RPC conversion, mempool/address, state-sync/import, and finally deep state-migration / StateRoot invariants. The work includes seed-corpus engineering, minimization, regression replay, crash triage, coverage reporting, sustained self-hosted campaigns, structured generation, and multiple hardening cycles. A public **zero-patch** PoC already proves the toolchain builds and runs against Forest's real block-header DAG-CBOR decoder: **7,689,772 executions in 61 seconds, 0 crashes, 7 header invariants asserted**. No milestone depends on Google OSS-Fuzz, ChainSafe coordination, or any third-party merge. 2.2 Who does this work support? [ "Network Infrastructure", "Storage Providers", "Application Builders" ] 2.3 Total Funding Requested (USD) 120000 2.4 Milestones & Budget [ { "title": "Milestone 1", "description": "Establish the foundation of the Forest fuzzing program against pinned commit `94cc463`: the standalone fuzzing crate, the visibility shim, and the first three P0 oracle-driven targets covering Forest's most exposed remote inputs.\n\nDeliverables:\n\n- Standalone, workspace-independent `cargo-fuzz` crate with a target registry and a pure-Rust build path (`FOREST_F3_SIDECAR_FFI_BUILD_OPT_OUT=1` + `--features no-f3-sidecar`, no Go toolchain), with reproducible setup documentation and build-smoke commands.\n- `fuzz_private` doc-hidden, feature-gated visibility shim on our Forest branch, re-exporting only the decode entry points needed for fuzzing (`GossipBlock`, `SignedMessage`, `CarBlock`, `AnyCar`), mirroring Forest's existing `doctest_private`/`benchmark_private`/`interop_tests_private` precedent — visibility bridge only, no consensus/parsing/runtime behavior change.\n- Three P0 oracle-driven fuzz targets: (1) `GossipBlock` decode (P2P blocks topic), (2) `SignedMessage` decode (mempool/messages input), (3) CAR block/snapshot parsing via `CarBlock::from_bytes` / `AnyCar::try_from`. Each asserts oracles beyond raw decode: no-panic on hostile input, decode-encode-decode round-trip determinism, CID/content consistency, bounded-resource behavior, method/field panic-safety. The CAR target specifically checks CID-vs-content consistency and bounded allocation, since attacker-controlled CAR length fields are a resource-amplification surface.\n- Initial seed corpora for all three targets, extracted as a one-off manual pass from Forest's committed test snapshots (`test-snapshots/chain4.car` and related), bundled mainnet/calibnet genesis CARs, and public fixtures, normalized and documented (scripted pipeline scoped to M2; `cmin`/`tmin` minimization to M3).\n- Local runner scripts, reproduction commands, crash-artifact layout, and regression seed path.\n- S/H/R/F crash-triage template with the anti-overclaim rule: crashes are not security vulnerabilities until reachability and impact are established.\n- Input-surface analysis note per target: Forest module, decode entry point, reachability, oracle design.\n- Baseline run logs per target: executions, exec/sec, coverage notes, crash/timeout/OOM outcomes.", "dueDate": "2026-08-31", "fundingRequested": "20000", "completionCriteria": "- Fuzzing branch pinned to Forest commit `94cc463` with documented branch/worktree layout and target registry.\n- `cargo-fuzz` crate builds and runs in pure Rust (no Go) with documented commands.\n- `fuzz_private` shim implemented as an upstream-ready local patch, re-exporting only target decode entry points, zero behavior change.\n- `GossipBlock`, `SignedMessage`, and CAR targets run locally with their documented oracle sets (firm commitment — no blocker/substitution clause applies to the three M1 targets).\ …[truncated] 3.1 Impact pathway **Output** — open-source Forest fuzzing infrastructure: runnable targets, seed corpora, minimization workflows, sustained campaign logs, regression replay, coverage artifacts, hardening patch sets, final report. **Outcome** — Forest's parser/import/network/RPC/sync boundaries are continuously exercised against adversarial input instead of being covered only by conventional tests. Confirmed edge cases become regression seeds; confirmed issues become patches or documented fixes. Operators and downstream infrastructure get a reusable way to reproduce and extend security testing. **Impact** — stronger Filecoin client resilience and lower operational risk for anything that depends on Forest. Reducing the chance that parsing/import bugs, resource exhaustion, malformed network data, or state/sync edge cases disrupt syncing, SP operations, or user workflows **indirectly** supports paid onchain deals and flagship adoption — and strengthens Filecoin's multi-client health story by hardening the Rust node, not only the dominant Go client. 3.2 Verification metrics **Output** — open-source Forest fuzzing infrastructure: runnable targets, seed corpora, minimization workflows, sustained campaign logs, regression replay, coverage artifacts, hardening patch sets, final report. **Outcome** — Forest's parser/import/network/RPC/sync boundaries are continuously exercised against adversarial input instead of being covered only by conventional tests. Confirmed edge cases become regression seeds; confirmed issues become patches or documented fixes. Operators and downstream infrastructure get a reusable way to reproduce and extend security testing. **Impact** — stronger Filecoin client resilience and lower operational risk for anything that depends on Forest. Reducing the chance that parsing/import bugs, resource exhaustion, malformed network data, or state/sync edge cases disrupt syncing, SP operations, or user workflows **indirectly** supports paid onchain deals and flagship adoption — and strengthens Filecoin's multi-client health story by hardening the Rust node, not only the dominant Go client. ### 3.2 Verification metrics No direct onchain KPI moves; this is indirect core infrastructure. The externally verifiable metrics are engineering outputs: | Metric | Data source | Measured by | Target (end of grant) | |---|---|---|---| | Operational fuzz targets | Public branch/repo | Clean checkout runs targets via documented commands | Full P0/P1 set, ~15–18, or documented blockers | | Public PoC feasibility | `forest-fuzz-poc` | Reviewer reproduces build/run against `94cc463` | Already demonstrated pre-submission | | Sustained campaigns | Run logs/report | Per-target runtime, throughput, crash/timeout/OOM | M1–M2 baseline, M3 first burn-in, M6 final long burn-in | | Seed corpus workflow | Public corpus/scripts | `cmin`/`tmin`/dedup documented + reproducible | Per-target minimized corpus + regression layout | | Coverage reporting | Coverage artifacts | Baseline + delta per module | Baseline, mid-project delta, final gap analysis | | Regression replay | Public run scripts | Confirmed crashes/edge cases replay deterministically | Replay workflow + repro commands | | Advanced semantic targets | Public target code/report | State-root/CID/receipt-root or equivalent oracle | ≥1 deep invariant target or substituted P1 | | Hardening outputs | Patch set/report | Patches/notes for confirmed findings | Two hardening cycles; fixes/tooling where practical | 3.3 References 1. Public PoC repository and evidence: https://github.com/robustfengbin/forest-fuzz-poc 2. Prior accepted fuzzing-grant model: ZCG #234 "Zebra Coverage-Guided Fuzzing Infrastructure" (accepted Zcash Community Grant, same project lead): https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/234 3. Forest upstream: https://github.com/ChainSafe/forest 4.1 Monthly Operating Burn [ "$10-$100K (small team)" ] 4.2 What % of total team monthly burn depends on this grant? 50 4.3 If this grant is not awarded, what happens? Without this grant, the 6-month program — production fuzz targets, corpus and regression infrastructure, sustained campaigns, and hardening cycles by two dedicated Rust/security engineers — would not be built; only the public feasibility PoC would remain. Given the continuing history of infrastructure-level failures across web3, Forest's untrusted-input surfaces would remain an under-tested risk area: a consensus-critical Filecoin client without systematic coverage-guided fuzzing, where parser, import, RPC, sync, or resource-exhaustion failures could affect storage providers and applications that depend on it. 4.4 Core Team Robust — Project Lead & Independent Security Engineering Lead; senior engineer, 15+ years building production backend systems and developer tooling, strong in Rust, distributed systems, blockchain infrastructure, and coverage-guided fuzzing. Robust was Project Lead of ZCG #234 "Zebra Coverage-Guided Fuzzing Infrastructure" — a directly analogous coverage-guided fuzzing program for Zebra, Zcash's Rust consensus node — which establishes hands-on experience with cargo-fuzz/libFuzzer target design, blockchain-derived seed-corpus workflows, CI-oriented fuzzing, and severity-based crash triage for a Rust blockchain node. This work has already produced publicly credited security results on Zebra: a Critical-severity remote denial-of-service (CVE-2026-34202 / GHSA-qp6f-w4r3-h8wg) — a single crafted P2P message crashing the node, no authentication required — discovered through this fuzzing methodology and coordinated-disclosed, with public credit from the Zcash Foundation and the fix shipped in Zebra 4.3.0; and a V6 transaction-hash panic caught ahead of the NU7 network upgrade (public issue #10534). Additional robustness and code-quality findings have been reported upstream. This application applies the same methodology to Forest, a sibling Rust node. The work is carried by a small two-engineer Rust/security team focused on fuzzing, input-surface analysis, corpus engineering, triage, structured generation, sustained campaigns, and hardening. The team has already shipped a public zero-patch Forest header-decode PoC against the real codebase. 4.5 Has your team received a ProPGF grant or funding from PLFIF before? [ "No" ] 5.1 Key risks & dependencies **Risk:** Forest internal modules are private; an external fuzz crate can't import some target types. **Mitigation:** Small local `fuzz_private` doc-hidden visibility shim following Forest's `doctest_private` / `benchmark_private` / `interop_tests_private` precedent. Visibility bridge only; no consensus/runtime change; no ChainSafe review/merge required. **Risk:** Upstream PR review / merge timing / maintainer preference is outside our control. **Mitigation:** Upstream coordination is optional follow-up. Acceptance is on our branch/fork being documented, tested, and runnable — the same boundary logic that excludes Google OSS-Fuzz from deliverables. **Risk:** Fuzzing may find few or no vulnerabilities (Rust safety + existing tests cover much). **Mitigation:** Success = durable, reproducible infrastructure, measured coverage, sustained campaigns, regression replay, hardening — not vulnerability count. The suite targets panics, resource exhaustion, decode consistency, invalid-state handling, and regression seeds. **Risk:** CI fuzzing is too heavy for normal PR checks. **Mitigation:** Short smoke runs for PR-style checks; longer scheduled/nightly self-hosted campaigns; heavyweight corpora/artifacts managed separately from normal builds. **Risk:** Security findings need careful disclosure. **Mitigation:** All findings use the S/H/R/F taxonomy. Potentially exploitable findings are privately disclosed before public detail; hardening/regression cases are reported without exaggerating impact. **Risk:** The 6-month scope is larger than the feasibility PoC. **Mitigation:** The PoC already de-risked the toolchain and Forest build path. The six monthly milestones are independently verifiable outputs (targets, corpora, logs, replay, advanced targets, patch sets, final burn-in). Contributing to Core Infrastructure? Forest is a critical Rust implementation of a Filecoin full node. It processes untrusted network input, chain data, signed messages, block headers, snapshots, CAR files, RPC conversion boundaries, and sync/import data. Forest node operators, storage providers, application builders, and Filecoin network infrastructure depend on this implementation being robust under malformed or adversarial inputs. This project builds and runs open-source coverage-guided fuzzing and hardening infrastructure for Forest's high-risk input surfaces — contributing security testing infrastructure rather than replacing Forest maintenance, which is handled by ChainSafe. Objective 1 Indirect Objective 2 N/A Objective 3 Indirect Open Source Context This project is fully open source. The pre-submission proof of concept is already public at https://github.com/robustfengbin/forest-fuzz-poc, and all funded work will be published openly: fuzz harnesses, corpus tooling, runner scripts, reproducible run commands, coverage artifacts, reports, and hardening patch sets. The only material that is not released immediately is the exploit-level detail of any security-sensitive finding: such findings are first disclosed privately through the appropriate Filecoin/Forest security channel, with enough public detail for grant accountability, and full details published after a fix is available. This responsible-disclosure practice protects Filecoin network reliability and aligns with the network's objective of a secure, resilient multi-client node ecosystem.