TinyRustLM Hostile-Artifact Hardening, Fuzzing, Differential Testing, and Formal-Invariant Program

Full report

On this page

Executive hardening strategy and assumptions

Evidence labels used throughout this report

Scope. The uploaded engineering brief makes the research topic specific: hardening TinyRustLM against malformed, adversarial, oversized, inconsistent, and resource-exhausting inputs across model files, manifests, receipts, tokenizer data, grammars, networking, browser/WASM boundaries, archives, and native APIs. It also fixes important constraints: safe Rust by default, bounded validation before allocation or execution, no permissive compatibility readers for unpublished formats, privacy-safe diagnostics, immutable failure evidence, and fail-atomic preservation of the last-known-good state.

Assumption. No private TinyRustLM source, parser implementations, file-format specifications, binaries, corpora, crash records, CI configuration, or operational limits were available. Consequently, this report defines implementation contracts, harness shapes, invariants, and verification gates, but it does not claim that the present product satisfies them.

Executive conclusion. TinyRustLM should treat every byte sequence crossing a trust boundary as hostile, including bytes obtained from “trusted” catalogs, local files, loopback services, same-origin browser messages, package consumers, and previously cached artifacts. Provenance can influence authorization and reputation; it cannot substitute for structural validation. Safe Rust materially reduces classes of memory corruption, but it does not prevent integer-wrap logic errors, unbounded allocation, stack exhaustion, algorithmic complexity attacks, deadlocks, semantic ambiguity, or state corruption caused by valid-but-malicious inputs. Rust’s own reference distinguishes soundness from broader application safety, and its undefined-behavior rules do not purport to prevent denial of service or business-logic failures.

The recommended architecture is a bounded admission pipeline:

untrusted bytes
    ↓
transport envelope limits
    ↓
bounded structural preflight
    ↓
canonical representation and exact-consumption check
    ↓
semantic and cross-object validation
    ↓
cryptographic identity and signature verification
    ↓
resource plan and allocation approval
    ↓
quarantined preparation
    ↓
single fail-atomic activation commit

No later phase may compensate for a missing earlier bound. Hashing an enormous attacker-selected region is still resource consumption. Verifying a signature over ambiguous serialization does not create a canonical interpretation. Loading tensor data before proving all ranges and dimensions are bounded defeats preflight. Parsing in WebAssembly does not make excessive CPU or memory use acceptable.

Primary security objectives

Engineering recommendation. Use a small, independently reviewed admission core containing only byte cursors, checked arithmetic, limit accounting, structural parsers, canonical encoders, and immutable validated descriptors. It should not contain network clients, GPU code, model execution, dynamic dispatch into metadata, archive extraction, or application state mutation. The core should compile for native and wasm32, with the same acceptance semantics and the same domain error codes.

Engineering recommendation. Keep production dependencies near zero as requested, but explicitly permit test-only tools. cargo-fuzz wraps libFuzzer and is the standard Rust-oriented entry point; libFuzzer expects fast, deterministic, narrow, repeatedly callable harnesses and supports corpus minimization, dictionaries, timeouts, and RSS limits. AFL++ and honggfuzz provide useful independent mutation and scheduling behavior, while Miri, Loom, Kani, sanitizers, and deductive verifiers answer different questions. None constitutes a production guarantee on its own.

Assumptions requiring ratification

Attack surface and trust boundaries

The trust boundary is crossed when an attacker can influence bytes, lengths, ordering, identity, paths, destinations, timing, cancellation, or concurrency. A same-machine loopback socket, browser worker, package wrapper, or catalog entry is still a boundary because another process, tab, extension, compromised dependency, or stale cache can supply malformed values.

Attack-surface and trust-boundary matrix

Boundary-specific objectives

Binary artifacts. Every offset is a half-open interval [start, end) expressed in a fixed-width unsigned type until proven representable as usize. Entries must be nonoverlapping. Whether gaps are allowed must be a format-level decision; for core model data, the safer default is exact coverage so suffix polyglots and concealed secondary payloads are rejected. Safetensors illustrates several useful defensive choices: a length-delimited JSON header, disallowed duplicate keys, explicit tensor offsets, and a requirement that the tensor buffer be fully indexed without holes. Those choices are evidence that a tensor format can remain simple while imposing overlap and coverage invariants, not proof that TinyRustLM should copy the format unchanged.

Structured metadata. RFC 8785’s JSON Canonicalization Scheme requires no duplicate property names and defines a deterministic serialization, but it deliberately preserves string data rather than performing Unicode normalization. TinyRustLM must therefore choose whether identifiers are byte-exact, NFC-normalized before admission, or restricted to a conservative character subset; it must not allow one component to normalize while another signs or compares raw strings. Unicode normalization forms are stable and idempotent for their defined domains, but compatibility normalization can erase distinctions and should not be applied blindly.

Network framing. HTTP/1.1 explicitly warns that messages containing both Transfer-Encoding and Content-Length can facilitate request smuggling when recipients disagree. A strict loopback server should reject the combination and close the connection rather than rely on downstream interpretation. WebSocket receivers must enforce masking direction, fragmentation sequencing, control-frame size, and nonfragmentation rules. Per-message compression adds independent state and memory constraints, including negotiated window and context-takeover parameters.

Paths and archives. Textual prefix checks are inadequate because absolute paths, .., alternate separators, links, reparse points, namespace syntax, and time-of-check/time-of-use races can change the final target. Windows additionally has reserved names, NUL and control restrictions, alternate data streams, UNC and drive-relative forms, and symbolic links implemented as reparse points. CWE-22 recommends canonicalization and containment rather than solely filtering suspicious strings, while Microsoft’s filesystem documentation confirms the platform-specific namespace and link behavior that must be tested.

Path and archive admission contract

Engineering recommendation. Prefer reading package members directly from a validated container without extracting them. Where extraction is unavoidable:

1. Create a new, private staging directory owned by the operation.
2. Reject absolute, rooted, drive-relative, UNC, device, namespaced, empty, dot, parent, ADS-bearing, reserved-device, and NUL-containing member names before filesystem calls.
3. Convert separators according to a format-defined portable path grammar rather than host interpretation.
4. Reject symlink, junction, reparse-point, hard-link, device, FIFO, socket, and other nonregular entries unless a separately reviewed use case requires them.
5. Open each destination relative to a directory handle using no-follow semantics where supported.
6. After creation, resolve the actual object and verify containment under the staging root.
7. Refuse duplicate normalized paths and case-fold collisions on case-insensitive destinations.
8. Enforce aggregate expanded bytes, file count, directory count, per-file bytes, compression ratio, and CPU budget.
9. Never execute, import, or dynamically load extracted scripts or libraries.
10. Atomically publish only a fully validated staging tree; recursively delete failed staging trees using independent cleanup attempts.

Network parser test requirements

Universal bounded reader, checked arithmetic, and fail-atomic state

Bounded-reader contract

Engineering recommendation. All binary and structured parsers should consume input through one audited cursor abstraction or equivalent generated pattern. Direct indexing into attacker-controlled buffers should be prohibited in parser modules except inside that abstraction.

#[Figure omitted from source export: forbid(unsafecode)]

#[derive(Clone, Copy, Debug)]
pub struct ParseLimits {
    pub max_input_bytes: u64,
    pub max_items: u32,
    pub max_string_bytes: u32,
    pub max_nesting: u16,
    pub max_work_units: u64,
    pub max_planned_allocation: u64,
}

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub enum ParseCode {
    InputTooLarge,
    UnexpectedEof,
    IntegerOverflow,
    WidthNotRepresentable,
    CountLimit,
    StringLimit,
    NestingLimit,
    WorkLimit,
    AllocationLimit,
    InvalidUtf8,
    InvalidValue,
    DuplicateField,
    Overlap,
    Gap,
    TrailingBytes,
    UnsupportedVersion,
}

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub struct ParseError {
    pub code: ParseCode,
    pub stage: u16,
    pub field: u16,
    pub offset_bucket: u32,
}

pub struct Reader<'a> {
    bytes: &'a [u8],
    pos: usize,
    work: u64,
    limits: ParseLimits,
}

impl<'a> Reader<'a> {
    pub fn new(bytes: &'a [u8], limits: ParseLimits) -> Result<Self, ParseError> {
        let len = u64::try_from(bytes.len()).map_err(|_| err(ParseCode::WidthNotRepresentable))?;
        if len > limits.max_input_bytes {
            return Err(err(ParseCode::InputTooLarge));
        }
        Ok(Self { bytes, pos: 0, work: 0, limits })
    }

    pub fn remaining(&self) -> usize {
        self.bytes.len() - self.pos
    }

    pub fn position(&self) -> usize {
        self.pos
    }

    pub fn charge(&mut self, units: u64) -> Result<(), ParseError> {
        self.work = self.work
            .checked_add(units)
            .ok_or_else(|| err(ParseCode::IntegerOverflow))?;
        if self.work > self.limits.max_work_units {
            return Err(err(ParseCode::WorkLimit));
        }
        Ok(())
    }

    pub fn take(&mut self, n: usize) -> Result<&'a [u8], ParseError> {
        self.charge(u64::try_from(n).map_err(|_| err(ParseCode::WidthNotRepresentable))?)?;
        let end = self.pos
            .checked_add(n)
            .ok_or_else(|| err(ParseCode::IntegerOverflow))?;
        let out = self.bytes
            .get(self.pos..end)
            .ok_or_else(|| err(ParseCode::UnexpectedEof))?;
        self.pos = end;
        Ok(out)
    }

    pub fn read_u32_le(&mut self) -> Result<u32, ParseError> {
        let b: [u8; 4] = self.take(4)?
            .try_into()
            .map_err(|_| err(ParseCode::UnexpectedEof))?;
        Ok(u32::from_le_bytes(b))
    }

    pub fn read_len_u32(&mut self, maximum: u32) -> Result<usize, ParseError> {
        let value = self.read_u32_le()?;
        if value > maximum {
            return Err(err(ParseCode::CountLimit));
        }
        usize::try_from(value).map_err(|_| err(ParseCode::WidthNotRepresentable))
    }

    pub fn finish_exact(self) -> Result<(), ParseError> {
        if self.pos != self.bytes.len() {
            return Err(err(ParseCode::TrailingBytes));
        }
        Ok(())
    }
}

const fn err(code: ParseCode) -> ParseError {
    ParseError { code, stage: 0, field: 0, offset_bucket: 0 }
}

The public error carries only bounded numeric classifications. A private diagnostic layer may associate the failure with an artifact hash, build ID, target ID, and more precise offset, but must not include raw field contents or paths by default.

Required reader rules

Checked-arithmetic invariant library

Rust exposes checked integer methods such as checked_add and checked_mul; using them explicitly avoids relying on profile-dependent overflow behavior. The key design rule is to retain values as fixed-width format types until bounds are proven, then convert once to the destination width. usize differs between native 64-bit and wasm32, so successful native conversion is not evidence of WASM representability.

#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd)]
pub struct ByteCount(u64);

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub struct FileRange {
    pub start: u64,
    pub end: u64, // exclusive
}

impl ByteCount {
    pub fn checked_add(self, rhs: Self) -> Result<Self, ParseCode> {
        self.0.checked_add(rhs.0)
            .map(Self)
            .ok_or(ParseCode::IntegerOverflow)
    }

    pub fn checked_mul(self, rhs: u64) -> Result<Self, ParseCode> {
        self.0.checked_mul(rhs)
            .map(Self)
            .ok_or(ParseCode::IntegerOverflow)
    }

    pub fn as_usize(self) -> Result<usize, ParseCode> {
        usize::try_from(self.0).map_err(|_| ParseCode::WidthNotRepresentable)
    }
}

impl FileRange {
    pub fn new(start: u64, end: u64, file_len: u64) -> Result<Self, ParseCode> {
        if start > end || end > file_len {
            return Err(ParseCode::InvalidValue);
        }
        Ok(Self { start, end })
    }

    pub fn len(self) -> ByteCount {
        ByteCount(self.end - self.start)
    }

    pub fn overlaps(self, other: Self) -> bool {
        self.start < other.end && other.start < self.end
    }
}

pub fn checked_product(values: &[u64], maximum: u64) -> Result<u64, ParseCode> {
    let mut product = 1_u64;
    for &value in values {
        product = product
            .checked_mul(value)
            .ok_or(ParseCode::IntegerOverflow)?;
        if product > maximum {
            return Err(ParseCode::AllocationLimit);
        }
    }
    Ok(product)
}

Arithmetic proof obligations

Engineering recommendation. Add model-checking harnesses for each helper over small and boundary domains. Kani can prove assertions, panic absence, and arithmetic-overflow properties within bounded harnesses, but its documentation currently treats concurrency as out of scope; use it for pure arithmetic and parser helpers, not as evidence about activation races.

Parser phase separation

Prohibition. Decompression, if supported, must occur only after a compressed-size cap, declared expanded-size cap, ratio cap, codec policy, and output budget are established. Because a compressed stream can produce far more output than input, the decompressor must write through a bounded sink rather than allocate the declared output optimistically.

Fail-atomic state model

Bytes
  └──parse──> ParsedCandidate
                 └──validate──> ValidatedCandidate
                                    └──plan──> PlannedCandidate
                                                  └──prepare──> PreparedCandidate
                                                                    └──commit──> ActiveGeneration

A type representing an earlier phase must not expose methods belonging to later phases. This typestate pattern prevents accidental activation of merely parsed data, though it does not by itself prove runtime limits or concurrency behavior.

Required state-machine properties

Engineering recommendation. Make receipt append a separate, durable finalization operation. If the product must record failed attempts, append the failure record without changing the active-state pointer. If durable receipt append itself fails, expose that as an evidence failure without retroactively reclassifying a successful in-memory activation; the exact product rule needs local ratification.

Mutation, property-based testing, coverage-guided fuzzing, and differential testing

Mutation taxonomies

Property-based generator design

Property-based testing should generate both accepted structures and near-valid rejected structures. QuickCheck established the model of generated inputs and shrinking counterexamples, while later work combines property generation with coverage feedback. TinyRustLM need not make any such library a runtime dependency; generators belong in test-only modules.

Valid generators

Invalid near-valid generators. Begin with one valid generated object and violate exactly one named invariant: one duplicate key, one overlapping range, one incorrect tensor byte, one stale generation, one invalid range endpoint, one extra trailing byte, or one cancellation reordering. These generators provide clearer blame and better shrinking than wholly random invalid data.

Shrink strategy

Metamorphic and round-trip properties

Coverage-guided target matrix

libFuzzer guidance recommends narrow, deterministic, fast targets that tolerate arbitrary input, avoid uncontrolled global state, and join any threads before returning. AFL++ guidance similarly favors source-level persistent harnesses and discourages fuzzing real network services when the protocol parser can instead consume an in-memory byte stream.

Harness rules

A target must not access a live socket, production catalog, user directory, GPU, cloud memory service, real model execution, environment credentials, clipboard, or prompt history. It must reset operation-local state after every call and have no data-dependent logging. Any required hash key should be a fixed public test key. Time and randomness must derive only from the input or a fixed seed.

Corpus strategy

cargo-fuzz supports target execution, input minimization, corpus minimization, and coverage reporting. libFuzzer supports dictionaries, RSS and timeout controls, and reusable corpus directories; AFL++ supports dictionary-assisted campaigns and independent scheduling. Tool versions, compiler versions, target hashes, and corpora should be pinned so evidence is reproducible.

Differential testing and disagreement adjudication

Differential testing compares independent implementations to expose inconsistencies. The oracle is not “whatever most implementations do”: an observed disagreement starts an investigation against the format specification, arithmetic model, and platform semantics. An implementation can be consistently wrong, and two implementations can share a bug.

Engineering recommendation. Maintain an oracle hierarchy: written format contract, mathematical invariant, independent simple reference implementation, standards conformance suites, and only then production implementations. Every disagreement record should contain both implementation identities, target and corpus hashes, minimized input hash, outputs, applicable tolerance, and the decision explaining which side changed.

Formal methods, concurrency, sanitizers, browser, WASM, and WebGPU

Risk-targeted formal techniques

Engineering recommendation. Formalize only high-value, low-churn kernels first:

• checked_product, range construction, overlap detection, alignment, and u64 → usize conversion.
• Tensor byte-size equations for every dtype and quantization scheme.
• Canonical metadata encoding.
• Receipt-chain append and replay rules.
• Activation generation swap and stale-result rejection.
• WASM and C ABI pointer/length checks.

Avoid attempting whole-product formal verification before the format and state architecture stabilize. Proof effort attached to a changing permissive parser would preserve the wrong design.

Concurrency and race testing

Engineering recommendation. Put synchronization behind a small adapter that can use standard primitives in production and Loom primitives under cfg(loom). Keep model tests to two or three actors and short state sequences so state-space exploration remains tractable. Then supplement deterministic model checking with repeated native stress and TSan runs.

Native dynamic-analysis matrix

The Rust sanitizer documentation describes ASan and TSan as test/fuzzing tools, lists target-specific support, and notes that sanitizers add overhead and cannot catch every issue. cargo-fuzz itself requires LLVM sanitizer support and is documented for x86-64 and AArch64 Unix-like systems rather than Windows, so Windows assurance must include deterministic corpus replay, platform-native tests, and optionally a separate compatible fuzz engine or cross-compiled harness strategy.

Browser, WASM, and WebGPU test matrix

WebAssembly memories are page-based and exposed through JavaScript buffers. Memory growth can replace or detach prior fixed-length views, so JS wrappers cannot retain unversioned typed-array views across growth. WebGPU devices can be lost asynchronously; the specification advises applications to handle the loss, notes that resources from the old device must be recreated, and warns that implementation-defined loss messages should not be parsed or disclose unnecessary system information.

Engineering recommendation. Treat browser error messages and GPU validation text as untrusted diagnostics. Map them to TinyRustLM domain codes and store only a bounded hash or locally restricted detail record. Never return raw implementation-defined GPU or browser strings through public receipts.

Evidence retention, triage, CI, and staged security TDD

Resource isolation and campaign controls

Engineering recommendation. Long-running fuzzing and adversarial integration tests should execute in disposable child processes or containers with:

• A read-only build and seed corpus.
• A fresh writable artifact directory with no user data.
• No credentials, production endpoints, prompt history, SSH agents, cloud metadata access, or developer home-directory mounts.
• CPU time, wall time, resident memory, address-space, open-file, process, output-size and stack limits.
• Network disabled unless a specific isolated protocol integration test requires it.
• Deterministic locale, timezone, environment, and test keys.
• Crash artifacts named by cryptographic content hash rather than input-derived names.

libFuzzer provides per-input timeout, RSS, single-allocation and total-time controls, while AFL++ recommends explicit memory and timeout limits for pathological inputs. These are harness containment mechanisms, not substitutes for in-product bounds.

Privacy-safe evidence schema

CampaignRecord
  campaign_id
  tool_name
  tool_version_or_commit
  compiler_version
  target_name
  target_binary_hash
  source_revision
  corpus_manifest_hash
  dictionary_hash
  deterministic_seed
  start_time
  duration
  execution_count
  coverage_summary
  sanitizer_mode
  platform_and_architecture
  configured_limits

FailureRecord
  original_input_hash
  restricted_blob_location
  failure_class
  domain_error_or_signal
  bounded_stack_signature_hash
  target_hash
  first_seen_campaign
  minimized_input_hash
  minimizer_identity
  fix_revision
  regression_test_id
  disclosure_status

A bounded stack signature should contain normalized module/function identifiers and a small frame count, not full local paths, command lines, payload fragments, prompts, remote peer names, or environment variables. Public reports should describe the invariant and impact and may omit malicious bytes entirely.

Triage taxonomy

Immutable regression workflow

detect
  → content-address original bytes in restricted storage
  → reproduce under pinned target and tool
  → classify preliminary impact
  → minimize a copy, never the original
  → derive a generic nonsensitive regression where possible
  → fix narrowly or replace the parser/design
  → link fix, original hash, minimized hash and regression
  → rerun all invalidated phases and sibling implementations
  → authorize disclosure independently

Engineering recommendation. Failure records are append-only. A later determination such as “harness defect” adds a superseding classification record; it does not overwrite the original observation. This preserves auditability and satisfies the requirement that rejected artifacts remain traceable by hashes and bounded metadata.

CI schedule and coverage gates

Provisional parser-module gates

Stop rules. A campaign stops when its fixed budget expires, the target or source hash changes, containment fails, or a reproducible finding requires triage. Coverage plateau is a reason to rotate dictionaries, seeds, structured mutators or engines—not evidence that the target is safe. A target with no new coverage for a day should be reviewed for unreachable guarded paths, poor seed quality, excessive rejection before deep logic, or missing structured mutations. AFL++ likewise cautions that full coverage is generally unattainable and that prolonged plateaus may call for a different fuzzer or mutator.

Staged security TDD backlog

gantt
    title TinyRustLM hostile-input hardening sequence
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Admission core
    Inventory formats and set policy limits           :a1, 2026-08-03, 7d
    Checked arithmetic and interval library           :a2, after a1, 10d
    Universal bounded reader and error taxonomy       :a3, after a1, 10d
    Pure structural parsers                           :a4, after a2, 20d

    section Test foundations
    Valid and near-valid generators                   :b1, after a3, 14d
    Single-field corruption matrix                    :b2, after a4, 14d
    Metamorphic and canonicalization properties       :b3, after b1, 14d
    Corpus and immutable evidence store               :b4, after b1, 10d

    section Adversarial testing
    Coverage-guided parser targets                    :c1, after b2, 21d
    Differential native and WASM lanes                :c2, after b3, 14d
    HTTP WebSocket archive and ABI campaigns          :c3, after c1, 21d

    section State and concurrency
    Fail-atomic activation model                      :d1, after a4, 14d
    State-machine property tests                      :d2, after d1, 14d
    Loom TSan and repeated stress                     :d3, after d2, 21d

    section Dynamic and formal evidence
    ASan Miri and platform matrix                     :e1, after c1, 14d
    Kani arithmetic and range proofs                  :e2, after a2, 21d
    Browser WASM WebGPU fault injection               :e3, after c2, 21d

    section Release hardening
    Quarantined real-artifact campaigns               :f1, after c3, 14d
    Coverage review and permissive-path deletion      :f2, after e3, 14d
    Publication security gate                         :f3, after f2, 7d

Backlog sequence

Clean deletion rules

Because TinyRustLM is pre-publication, strict redesign should replace permissive readers rather than accumulate fallback modes.

A parsing path must be deleted when any of the following holds:

• It accepts inputs the normative writer cannot produce without a documented extension mechanism.
• It tolerates duplicate keys, overlapping ranges, trailing bytes, ambiguous lengths, unknown executable metadata, or lossy canonicalization.
• It performs allocation, decompression, mapping, GPU work, or state mutation before bounded structural validation.
• It has parser semantics different from native/WASM or from the canonical encoder.
• It exists only for malformed unpublished artifacts.
• Its safety argument depends on provenance rather than bytes.
• Its error path exposes uncontrolled input.

Before deletion, preserve the design decision, relevant failure hashes, test cases, and replacement revision. Delete production code, feature flags, dead tests that assert permissive acceptance, fixtures whose only purpose is compatibility with malformed unpublished output, and documentation suggesting fallback behavior. Retain generic rejection regressions and immutable evidence.

Recommended visual evidence

The main security dashboard should not emphasize raw execution count alone. A useful chart is a stacked coverage-and-rejection trend per parser target: new edges, stable edges, valid admissions, expected bounded rejections, timeouts, OOMs, crashes, and unresolved disagreements by campaign revision. A second useful visualization is an invariant heat map with parsers as rows and test techniques—unit, property, fuzz, differential, Kani, Miri, sanitizer, Loom, browser—as columns. A parser with high line coverage but no resource-bound or state-atomicity evidence should remain visibly incomplete.

Unknowns requiring private inspection and annotated primary-source bibliography

Facts requiring local or authorized verification

Annotated primary-source bibliography

All web sources below were retrieved on August 1, 2026. Live documentation and repositories should be pinned to a commit, release, compiler toolchain, or dated specification in TinyRustLM’s evidence manifest.

1. Rust Reference, “Behavior considered undefined.” Defines Rust soundness obligations and explicitly notes that unsafe does not relax undefined-behavior rules. It should ground any exceptional future proposal to introduce unsafe code. Official Rust Reference.

1. Rust standard-library integer documentation. Documents checked integer operations used by the proposed arithmetic layer. The implementation should pin the actual Rust toolchain and test both 64-bit native and 32-bit WASM targets. Official @@MKREPORTTOKEN0@@ documentation.

1. Rust Fuzz Book and cargo-fuzz. Official Rust fuzzing guidance and repository for libFuzzer-based Cargo targets, corpus minimization and coverage. The repository notes Unix-like x86-64/AArch64 and nightly/LLVM requirements. Rust Fuzz Book and @@MKREPORTTOKEN1@@ repository.

1. LLVM libFuzzer documentation. Primary documentation for deterministic in-process targets, corpus operation, dictionaries, timeouts, RSS limits, minimization and fork mode. LLVM libFuzzer.

1. AFL++ documentation and repository. Primary source for persistent harnesses, corpus minimization, dictionaries, independent scheduling and resource controls. The repository reported release 4.40c in March 2026 when retrieved. AFL++ repository and fuzzing-in-depth guide.

1. honggfuzz repository. Primary repository for a separate feedback-driven, persistent-capable fuzzer useful as a cross-engine check. honggfuzz.

1. Rust sanitizer documentation. Documents supported sanitizer modes, targets, instrumentation caveats and the distinction between testing tools and production protections. Rust Unstable Book sanitizer chapter.

1. Miri repository. Primary documentation for Rust UB detection, supported checks and limitations regarding FFI, networking, nondeterminism and concurrency exploration. Miri.

1. Loom repository. Primary documentation for concurrency permutation testing and its incomplete C11 modeling limitations. Loom.

1. Kani Rust Verifier. Primary documentation for bounded model checking, panic and overflow checks, contracts and concrete counterexamples; its feature-support page states that concurrency is outside current scope. Kani book and feature support.

1. Creusot and Prusti documentation. Primary project sources for contract-based deductive verification of Rust. These are candidates for stable arithmetic and state kernels, not automatic whole-product guarantees. Creusot User Guide and Prusti repository.

1. RFC 9112, HTTP/1.1. Normative treatment of message framing and the security risk of simultaneous Transfer-Encoding and Content-Length. RFC 9112.

1. RFC 9110, HTTP Semantics. Normative URI, request-target, range and semantic framework. RFC 9110.

1. RFC 6455 and RFC 7692. Normative WebSocket framing, masking, fragmentation, control-frame and per-message compression rules. RFC 6455 and RFC 7692.

1. RFC 8785, JSON Canonicalization Scheme. Defines deterministic JSON serialization, prohibits duplicate object names for JCS input, and preserves Unicode strings without normalization. RFC 8785.

1. Unicode Standard Annex on normalization. Revision 57 for Unicode 17.0.0, dated July 30, 2025, explains canonical and compatibility normalization, stability and conformance tests. UAX #15.

1. WebAssembly specifications. The core and JavaScript-interface specifications define memory limits, page sizing, memory growth and buffer behavior. TinyRustLM must still impose smaller application-level limits. WebAssembly core specification and WebAssembly JavaScript interface.

1. WebGPU specification. Defines validation and device-loss behavior, including asynchronous loss and implementation-defined messages. The retrieved current editor’s draft was updated in July 2026, while a dated January 2026 Candidate Recommendation Draft is also available for pinning. WebGPU specification.

1. Microsoft Windows filesystem documentation. Primary documentation for reserved names, namespaces, NUL and control restrictions, symbolic links/reparse points and alternate data streams. Naming Files, Paths, and Namespaces, Symbolic Link Programming Considerations, and Alternate Data Streams.

1. MITRE CWE-22. Authoritative weakness classification and mitigation discussion for path traversal, canonicalization, separator variants and diagnostic leakage. CWE-22.

1. Safetensors format repository. A useful primary reference for a data-only tensor format with explicit header length, tensor offsets, duplicate-key rejection and full buffer coverage. It is an architectural comparison, not a substitute for a TinyRustLM specification or independent review. Safetensors repository.

1. PyTorch security guidance and advisory. Current PyTorch documentation warns never to load untrusted data with torch.load; the official 2025 advisory documents an RCE affecting earlier weights_only=True behavior. This supports the rule that model artifacts must remain data-only and that “restricted” deserializers require adversarial testing. PyTorch @@MKREPORTTOKEN2@@ documentation and GHSA-53q9-r3pm-6pq6.

1. QuickCheck and coverage-guided property testing. Foundational and later primary research describing generated properties, shrinking and the complementary relationship between property-based and coverage-guided testing. QuickCheck publication record and Coverage Guided, Property Based Testing.

1. Differential testing. McKeeman’s foundational work motivates comparing implementations to expose inconsistencies; TinyRustLM should combine this method with a specification-based adjudication process. Differential Testing for Software.