zerocopy

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Product vulnerability (Tier OT1; supply-chain compromise is a separate category) │ $101 - $3,133.70 │ $126 - $3,916.70 Other security issue (Tier OT1 flat award) │ $500 │ $625 Submit a vulnerability CVE history 0 Last 12 months 1 Lifetime Memory safety 65 % Parsing/validation 20 % Info disclosure 10 % Denial of service 3 % Latest advisories Loading the feed Overview zerocopy is one of the most-depended-upon crates in the Rust ecosystem, pulled in transitively across a very large share of the crates.io graph including rand , networking stacks, and much of the Rust code shipping inside Android, Fuchsia and Windows components. Its star count is close to meaningless as a proxy; the fact that matters is what it does. It is the crate the ecosystem uses to safely reinterpret untrusted bytes as typed structs, so a soundness hole in zerocopy is a memory-safety hole in every parser built on top of it, in exactly the codebases that adopted Rust to eliminate memory-safety holes. That makes it the highest leverage-per-line target in Google's OT1 set. Google pays for reports through the Open Source Software VRP at Tier OT1, where a product vulnerability runs from $101 to $3,133.70 and a discretionary panel decides where in that band a finding lands. sorona.xyz adds 1.25× on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Google's tier file lists google/zerocopy at TIER_OT1, which puts the whole crate in scope on the Open Source Software VRP. A security bug in its own code is a product vulnerability priced at $101 to $3,133.70 The safe-transmutation traits and the derives that implement them, FromBytes , IntoBytes , KnownLayout , Immutable and Unaligned among them, along with the layout conditions each derive is supposed to prove before it fires Reference casting and the transmute macros: Ref , try_transmute! , transmute_ref! and transmute_mut! , plus the fallible entry points that split a byte slice into a typed value and a remainder The unsafe core in full: alignment, padding, provenance, validity invariants and the pointer arithmetic underneath every safe API built on top of it Layout computation for slices and dynamically sized types, including the size and alignment maths that decides where a cast ends The endian-aware integer types and the other helpers the crate publishes alongside the traits The no_std build and the minimum-supported-Rust-version code paths, where the safety argument differs from the mainline one and gets less review The repository and the crates.io release pipeline, which the program prices separately as a supply-chain compromise rather than as a product vulnerability Out of scope Downstream code that uses zerocopy correctly and wraps it unsoundly, a defect in the caller rather than in the crate Unsoundness in the Rust compiler or in core , which belongs to the Rust project Nightly-only behaviour and anything gated behind an unstable feature API ergonomics and documentation issues that carry no soundness consequence Miri warnings with no demonstrated, exploitable unsoundness behind them Anything privately disclosed to a third party before Google, which the VRP says will typically not qualify for a reward Most-valued findings A derive macro accepting a type whose layout makes the trait's safety contract false, letting untrusted bytes become a typed value with invalid invariants. That is the top of the memory-safety class dominating this crate at 65% of the recorded profile Out-of-bounds read or write reachable through Ref or one of the transmute macros on an attacker-controlled slice length or alignment Padding or uninitialised memory disclosed to the caller through IntoBytes , which turns a parsing crate into an information leak in every consumer A DST or slice layout computation that overflows or miscomputes, since those paths are exercised precisely where lengths come off the wire Any of the above shown to reproduce through a widely used dependent such as a networking or serialisation crate, turning a crate-level soundness hole into an ecosystem-level one Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. A soundness bug in this crate is memory corruption, so a merged patch is the realistic submission route and the panel will expect one or an equivalently precise demonstration Miri warnings on their own are not enough; show unsoundness that an attacker-controlled byte sequence can actually reach Downstream crates that misuse zerocopy are out of scope: the defect has to be in the crate's own safety argument Frame the report accurately: a bug in the crate's own code is a product vulnerability, while compromise of the repository or the crates.io release pipeline is a separate and differently priced supply-chain category Google's reward panel sets the amount at its discretion within the published band, so the tier ceiling is a maximum rather than an expectation Google's rules state that privately disclosing a flaw to a third party, for any purpose other than fixing it, will typically not qualify for a reward Disclosure Coordinated through Google Bug Hunters, with the fix landing in google/zerocopy and a release cut to crates.io. This crate's history runs through RustSec advisories rather than assigned CVEs, so expect a RustSec entry and researcher credit rather than an NVD record. Because Google treats a private disclosure to a third party as grounds for disqualification, file with Google directly and hold the detail until the fixed version is published. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability