max / shop
| 1 | //! Structured fuzz over the kitty graphics protocol's APC bodies. |
| 2 | //! |
| 3 | //! The second half of the shop soak pair, and a separate target from `vt` |
| 4 | //! rather than a mode of it: these are two grammars with no shared code and no |
| 5 | //! dependency edge between their crates. `shop-vt` reads a byte stream with |
| 6 | //! embedded state; this reads a body someone else has already delimited. The |
| 7 | //! seam between them is in the shop binary, which is the only crate that links |
| 8 | //! both. |
| 9 | //! |
| 10 | //! What is at stake here is not the parser's own memory, which is safe by |
| 11 | //! construction (`#![deny(unsafe_code)]`), but what it hands the host: shop |
| 12 | //! indexes a transmitted payload as pixels using dimensions the same untrusted |
| 13 | //! body supplied. So the oracle is about payloads arriving intact and about |
| 14 | //! answers a client can act on, not about not panicking. |
| 15 | //! |
| 16 | //! ## The oracle lives in the crate, not here |
| 17 | //! |
| 18 | //! Everything asserted is `kittygfx::oracle::check_bodies`. The committed |
| 19 | //! regression replay in `tests/regressions.rs` calls the same function on |
| 20 | //! stable, so a crash found here becomes a unit test by copying one file, and |
| 21 | //! neither side can drift into checking less than the other. |
| 22 | //! |
| 23 | //! ## Input shape |
| 24 | //! |
| 25 | //! The input is split on ESC, with a leading `_` and a trailing `\` stripped |
| 26 | //! from each piece, so a capture of what a real client sends is a seed as it |
| 27 | //! stands. |
| 28 | |
| 29 | |
| 30 | |
| 31 | use fuzz_target; |
| 32 | |
| 33 | fuzz_target! |
| 34 | check_bodies; |
| 35 | ; |
| 36 |