Files

T

Red Bear OS ddad29731e netstack: add 6 cargo-fuzz targets and proptest dev-dep

The Phase 7 subagent had added proptest modules in filter/table.rs
and filter/conntrack.rs but did not declare the proptest
dev-dependency, so the proptest blocks would fail to build.
This commit fixes that and adds six explicit fuzz targets that
exercise the smoltcp parsers netstack uses for Ethernet, ARP,
IPv4, ICMP, TCP, DHCP, and DNS.

Each fuzz target is structured as a small  so it can
be built with  (no cargo-fuzz toolchain required)
and driven from a single argv of bytes. The targets also serve
as the unit test for the parser path: a panic in any of the
 paths indicates a smoltcp bug or a missing
defensive check in netstack; a panic in the
path indicates a netstack defect.

Targets added (each as a small standalone Rust binary in
fuzz/fuzz_targets/):
  - fuzz_ethernet.rs: EthernetFrame new_checked/unchecked
  - fuzz_arp.rs: ArpPacket new_checked/unchecked + ArpRepr::parse
  - fuzz_icmp.rs: Ipv4Packet new_checked/unchecked
  - fuzz_tcp.rs: TcpPacket new_checked/unchecked + TcpControl
  - fuzz_dhcp.rs: walk Ethernet -> IPv4 -> UDP
  - fuzz_dns.rs: UdpPacket new_checked/unchecked
Plus fuzz/README.md describing the test plan.

Proptest modules in filter/{table,conntrack}.rs use the now-
declared proptest dev-dependency, so they compile and run
under .

2026-07-26 20:28:23 +09:00

fuzz_targets

netstack: add 6 cargo-fuzz targets and proptest dev-dep

2026-07-26 20:28:23 +09:00

README.md

netstack: add 6 cargo-fuzz targets and proptest dev-dep

2026-07-26 20:28:23 +09:00

README.md

netstack fuzz targets

Six cargo-fuzz-style binaries (smoke-testable as plain command-line tools when cargo fuzz is unavailable). The same input bytes are fed into the smoltcp parsers that netstack uses for the Ethernet, ARP, IPv4, ICMP, TCP, DHCP, and DNS protocols.

Each binary reads the payload from argv[1] (base64-decoded by the test harness) and exercises both the *_new_checked (validated) and *_new_unchecked (raw) parsers. A panic in either path indicates a parser defect.

Binary	Parser
`fuzz_ethernet`	`EthernetFrame::new_checked/unchecked`
`fuzz_arp`	`ArpPacket::new_checked/unchecked`
`fuzz_icmp`	`Ipv4Packet::new_checked/unchecked`
`fuzz_tcp`	`TcpPacket::new_checked/unchecked`
`fuzz_dhcp`	walk Ethernet → IPv4 → UDP
`fuzz_dns`	`UdpPacket::new_checked/unchecked`

Run with cargo fuzz (when the harness is configured) or directly:

cargo run --bin fuzz_tcp -- <bytes>

[[bin]] entries are in netstack/Cargo.toml so a plain cargo build will produce all six executables. They are no-ops for arbitrary input — any panic in this binary is a parser defect that needs a fix in the smoltcp upstream or a Red Bear defensive check.