Report suspected vulnerabilities privately to info@microperceptron.com. Please do not open a public GitHub issue for a suspected vulnerability, and please do not disclose details publicly before we have agreed on a timeline.
A useful report includes:
- the affected crate and version, or commit hash;
- which trust boundary the issue crosses — see docs/threat-model.md;
- the bytes, call sequence, or descriptor-chain shape that triggers it, ideally as a failing test or a fuzz input; and
- the impact you believe it has.
Reports in any form are welcome. A plain description is worth more than no report at all.
This project is pre-standardization work maintained on a best-effort basis. These are the targets we hold ourselves to, not a contractual service level:
| Stage | Target |
|---|---|
| Acknowledgement of your report | 3 business days |
| Initial assessment, with a severity and a plan | 10 business days |
| Fix released, or a public advisory explaining why not | 90 days from acknowledgement |
We will tell you if a stage is going to slip. If you have not heard from us within 10 business days, please follow up — a missed mail is far more likely than a decision to ignore you.
We will credit you in the advisory and release notes unless you ask us not to. There is no bug bounty.
| Version | Supported |
|---|---|
Cargo 0.1.x |
Yes — the current line, and the only one receiving fixes |
| Protocol 1.0 wire ABI | Yes — frozen by the freeze audit |
Only the most recent 0.1.x release receives security fixes. There are no earlier published
releases, and no long-term-support branch. Support for a given line ends when its successor is
published, unless a release note says otherwise.
A fix that changes accepted or emitted protocol bytes is a wire-compatibility event, not only a Cargo release. It is classified under docs/release-policy.md like any other protocol change, and may require a new conformance directory even when it is a security fix.
In scope, in the crates published from this repository:
- memory-safety or panic reachability from untrusted input — protocol bytes, descriptor-chain shapes, or configuration values;
- unsound handling of unknown opcodes, statuses, flags, event states, or reserved bits;
- a device-side path that leaks guest addresses, virtqueue descriptors, or another context's data across the boundaries described in docs/threat-model.md;
- unbounded resource growth reachable from a bounded guest request; and
- any breach of the
#![forbid(unsafe_code)]invariant recorded in docs/release-policy.md.
Out of scope:
virtio-accel-mockandvirtio-accel-conformanceused as production components. They are test-only reference code with deterministic, non-secret artifacts and scripted faults.- Reserved-but-unassigned protocol values. A constant that records a reserved number is not permission for a device to advertise it; a device that does is out of specification.
- The absence of a claimed Virtio device ID. That is deliberate and documented.
- Vulnerabilities in a downstream VMM, kernel, operating system, or vendor adapter that merely depends on these crates. Please report those to the relevant project.
Published advisories will appear in this repository's GitHub Security Advisories and, where a crates.io release is affected, via the RustSec advisory database. Dependency advisories are checked in CI by cargo-deny; see docs/portability.md.