HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rust-fuzz
trophy-case
Testing & Quality2017–2026
rust-fuzz / trophy-case

trophy-case

🏆 Collection of bugs uncovered by fuzzing Rust code

Testing & Quality
Explore on GitHubRead Hacker News discussions
8Distinct people
14Mentions
0Explicit recommenders
457GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

🏆 Collection of bugs uncovered by fuzzing Rust code

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year14 dated mentions

Observed mentions: 2017-07-12 16:54:56 UTC to 2026-07-03 03:26:26 UTC.

012342017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC312
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

14 sources
pornel·Jul 3, 2026
> But you can just use very similar structures yourself in C programs! You can prevent problems in C as well by construction, even when the compiler does not enforce it. Enforcement is the point. Otherwise you're just saying people should be writing bug-free programs. "By construction" doesn't mean it's possible to construct a program satisfying a requirement, but that the compiler ensures it's impossible to violate it. Even for a hypothetical perfectly diligent flawlessly executing programmer it's a time saver. If you want to run a 3rd party function across threads: in Rust, the compiler tells you if it's thread-safe or not, tracing through all dependencies, callbacks, checking data structures, mutexes, ref counts, etc. And it works the other way, if I change a function that used to be thread-safe to do something unsynchronised, it won't
Read the rest
compile any more in users' multi-threaded programs, instead of silently screwing them. Their code may have been perfectly correct before the change, and I couldn't feasibly track down everyone using my function before making a change, but having invariants in the type system automates this checking and communication. > Just look at some of the bugs found in Rust, it is just the same old nonsense as everywhere You're comparing your perfect self who writes flawless C on the first try with some random guy's library. Properly designed Rust written by flawless Rust programmers is also bug-free. Language safety is a human problem (exists to catch mistakes), and it's hard to sensibly argue whether your imaginary average C programmer is better than mine. Rust's claims aren't absolute, so aren't disproven by a single counter-example (https://infosec.exchange/@littlealex/116838684458539473) It's better to look at broader data, e.g. https://github.com/rust-fuzz/trophy-case - look how much lower typical severity is there. And you can look at data from Google where they track drop in defect density in Android as it gets rewritten in Rust. I know all these top engineering companies just aren't as flawless as you are, and that's okay, Rust is for the rest of us.
In The C to Rust migration book
pornel·Jun 14, 2026
Incremental/quantitative improvement isn't disproven by contradiction. Anecdote is not data. Look at a bigger dataset, e.g. https://github.com/rust-fuzz/trophy-case there's a ton of overflows that result in caught panics or OOMs, and not bypasses. It works to reduce defect rate and severity. Note that C's tools for this like Valgrind, instrumented allocators and LLVM sanitizers work with Rust too. Investment in catching these in C generally helps unsafe Rust too, but Rust also has Miri, and a much better baseline for static analysis.
In Twenty One Zero-Days in FFmpeg
pornel·Feb 28, 2024
Vulnerabilities are where programmers thought the bounds checks were redundant, and they weren't. This overprotectiveness by default turns out to be useful: https://github.com/rust-fuzz/trophy-case Look how many of the crashes are panics and unwraps that could have been buffer overflows or wild pointer derferences otherwise. And there are plenty of arithmetic overflows that are much less dangerous when they can't cause out of bounds access. The code in this particular codec seems to be a direct translation of C code. Idiomatic Rust code would use iterators more, which work better for optimizing out redundant checks. It's easily fixable.
In Rewrite the VP9 codec library in Rust
pornel·Dec 2, 2021
You need to read the list more carefully. • The list is not for Rust itself, but every program ever written in Rust. By itself it doesn't mean much, unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs. Rust doesn't promise to be bug-free, but merely catch certain classes of bugs in programs that don't opt out of that. And it delivers: see how memory unsafety is rare compared to assertions and uncaught exceptions: https://github.com/rust-fuzz/trophy-case • Many of the memory-unsafety issues are on the C FFI boundary, which is unsafe due to C lacking expressiveness about memory ownership of its APIs (i.e. it shows how dangerous is to program where you don't have the Rust borrow checker checking your code). • Many bugs about missing Send/Sync or evil trait implementations are about type-system
Read the rest
loopholes that prevented compiler from catching code that was already buggy. C doesn't have these guarantees in the first place, so in C you have these weaknesses all the time by design, rather than in exceptional situations.
In This shouldn't have happened: A vulnerability postmortem
pcwalton·Aug 30, 2019
> 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. We actually have an objective experiment to answer this question: the rust-afl trophy case [1]. It is remarkable how different it is from the upstream AFL trophy case, which tests C and C++ code [2]. An enormous fraction of the AFL trophy case uncovered potentially-exploitable memory safety issues; by contrast, very few of the Rust issues were, with most being safe panics. [1]: https://github.com/rust-fuzz/trophy-case [2]: http://lcamtuf.coredump.cx/afl/
In Linux kernel drivers in Rust might become an option in the future
paulgdp·Nov 5, 2018
The Rust ecosystem has a team that tries to fuzz as many crates (rust packages) as possible [1]. Unlike C/C++ and like Python, fuzzing Rust code is not really about finding memory bugs but more about finding logical errors [2]. To do this, a project has been set up with 83 (so far) targets fuzzing the public API of 48 (so far) important crates [3]. All those targets can be fuzzed using any of the three major native code feedback-based fuzzers (AFL, LibFuzzer, and Honggfuzz). [1] https://github.com/rust-fuzz/targets [2] see the trophy case: https://github.com/rust-fuzz/trophy-case [3] https://github.com/rust-fuzz/targets/blob/master/common/src/... Disclaimer: I'm a member of this team and the author of the honggfuzz crate that makes honggfuzz work with Rust code.
In Generating Software Tests: Breaking Software for Fun and Profit
ekidd·Sep 27, 2017
> The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. I ran into a similar use case in one of my own projects—a vobsub subtitle decoder, which parses complicated binary data, and which I someday want to run as web service. So obviously, I want to ensure that there are no vulnerabilities in my code. I wrote the code in Rust, and then I used 'cargo fuzz' to try and find vulnerabilities. After running a billion(!) fuzz iterations, I found 5 bugs (see the 'vobsub' section of the trophy case for a list https://github.com/rust-fuzz/trophy-case). Happily, not one of those bugs could actually be escalated into an actual exploit. In each case, Rust's various runtime checks successfully caught the problem and turned it into a controlled pa
Read the rest
nic. (In practice, this would restart the web server cleanly.) So my takeaway from this was that whenever I want a language (1) with no GC, but (2) which I can trust in a security-critical context, Rust is an excellent choice. The fact that I can statically link Linux binaries (like with Go) is a nice plus.
In Chrome OS KVM - A component written in Rust
ekidd·Jul 12, 2017
> If AFL would catch the same bugs, Rust isn't better than C in this case. You can find a list of my vobsub bugs in the Rust Fuzz Trophy Case: https://github.com/rust-fuzz/trophy-case They are: 1. The shift overflow: This was harmless in both C and Rust, I believe. 2. The arithmetic overflow: This was a runtime panic in Rust, resulting in a clean crash. In C, this might have been exploitable with a complex enough attack. 3. The three "invalid slice" errors. All of these were clean runtime panics in Rust, and I'm pretty sure that at least two of them would have been exploitable in C with enough work. So Rust has a couple of advantages here. Out of 5 errors found by the fuzzer, the worst thing that could happen in Rust would have been crashing the program in a controlled fashion. In C, we would have been looking at memory corruption and qui
Read the rest
te possibly escalation. Secondly, Rust's runtime checks actually make fuzzers work better. Even simple checks like "is the end index of this slice great >= to the beginning index?" tend to catch problems almost as soon as they occur.
In Why you should, actually, rewrite some of it in Rust

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.