WEwesturner·Aug 24, 2025
google/syzkaller @main:
https://github.com/google/syzkaller
But there is also fuzztest?
google/fuzztest:
https://github.com/google/fuzztest
In Google Develops KFuzzTest for Fuzzing Internal Linux Kernel Functionsgoogle
syzkaller
Go2017–2025
google / syzkaller
syzkaller
syzkaller is an unsupervised coverage-guided kernel fuzzer
19Distinct people
21Mentions
0Explicit recommenders
6.4KGitHub stars
What to know before exploring
What it is
syzkaller is an unsupervised coverage-guided kernel fuzzer
GitHub
Where it is used
No documented product use was verified in the last source check.
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, 3:56:07 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 year21 dated mentions
Observed mentions: 2017-01-25 20:36:30 UTC to 2025-08-24 04:38:52 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
21 sourcesI case anyone else didn't recognize that word: https://github.com/google/syzkaller
In I used o3 to find a remote zeroday in the Linux SMB implementation"Automated Unit Test Improvement using Large Language Models at Meta" (2024)
https://arxiv.org/abs/2402.09171 :
> This paper describes Meta's TestGen-LLM tool, which uses LLMs to automatically improve existing human-written tests. TestGen-LLM verifies that its generated test classes successfully clear a set of filters that assure measurable improvement over the original test suite, thereby eliminating problems due to LLM hallucination. [...] We believe this is the first report on industrial scale deployment of LLM-generated code backed by such assurances of code improvement.
Coverage-guided unit test improvement might [with LLMs] be efficient too.
https://github.com/topics/coverage-guided-fuzzing :
- e.g. Google/syzkaller is a coverage-guided syscall fuzzer: https://github.com/google/syzkaller
- Gitlab CI supports coverage-guided fuzzing
Read the rest
: https://docs.gitlab.com/ee/user/application_security/coverag...
- oss-fuzz, osv
Additional ways to improve tests:
Hypothesis and pynguin generate tests from type annotations.
There are various tools to generate type annotations for Python code;
> pytype (Google) [1], PyAnnotate (Dropbox) [2], and MonkeyType (Instagram) [3] all do dynamic / runtime PEP-484 type annotation type inference [4] to generate type annotations. https://news.ycombinator.com/item?id=39139198
icontract-hypothesis generates tests from icontract DbC Design by Contract type, value, and invariance constraints specified as precondition and postcondition @decorators:
https://github.com/mristin/icontract-hypothesis
Nagini and deal-solver attempt to Formally Verify Python code with or without unit tests: https://news.ycombinator.com/item?id=39139198
Additional research:
"Fuzz target generation using LLMs" (2023)
https://google.github.io/oss-fuzz/research/llms/target_gener... https://security.googleblog.com/2023/08/ai-powered-fuzzing-b... https://hn.algolia.com/?q=AI-Powered+Fuzzing%3A+Breaking+the...
OSSF//fuzz-introspector//doc/Features.md: https://github.com/ossf/fuzz-introspector/blob/main/doc/Feat...
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C43&q=Fuz... :
- "Large Language Models Based Fuzzing Techniques: A Survey" (2024) https://arxiv.org/abs/2402.00350 :
> This survey provides a systematic overview of the approaches that fuse LLMs and fuzzing tests for software testing. In this paper, a statistical analysis and discussion of the literature in three areas, namely LLMs, fuzzing test, and fuzzing test generated based on LLMs, are conducted by summarising the state-of-the-art methods up until 2024
The key to modern fuzzing is feedback, usually some kind of coverage measurement of the program under test. This allows the fuzzer to be much smarter about how it finds new code paths and discards inputs that don't extend coverage. This makes fuzzing find bugs a lot quicker.
Google have a project to do fuzzing on Linux system calls using coverage feedback: https://github.com/google/syzkaller
In Fuzz testing: the best thing to happen to our application testsSystem call: https://en.wikipedia.org/wiki/System_call
Strace and similar tools can trace syscalls to see what kernel system calls are made by a process: https://en.wikipedia.org/wiki/Strace#Similar_tools
Google/syzkaller https://github.com/google/syzkaller :
> syzkaller ([siːzˈkɔːlə]) is an unsupervised coverage-guided kernel fuzzer. Supported OSes: Akaros, FreeBSD, Fuchsia, gVisor, Linux, NetBSD, OpenBSD, Windows
Fuschia / Zircon syscalls: https://fuchsia.dev/fuchsia-src/reference/syscalls
"How does Go make system calls?"
https://stackoverflow.com/questions/55735864/how-does-go-mak...
In Linux System Call Table – ChromiumosAlso see https://github.com/google/syzkaller - lots of kernel bugs found by this one
In Gustave – Embedded OS kernel fuzzerI'd start with reading the libfuzzer docs[0] and then read the syzkaller papers[1]
[0] https://llvm.org/docs/LibFuzzer.html
[1] https://github.com/google/syzkaller
https://github.com/google/syzkaller
In Kernel state based fuzzer: a LLVM approachSyzkaller fuzzes that stuff. https://github.com/google/syzkaller
In Linux 3.8 introduced unprivileged user namespaces [pdf]> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?
Because they have no other option, it's a fuzzer. Therefore, it may take a long time(up to universe heat death) for it to finally exercise the path that causes the issue. And the kernel has a pretty enormous footprint.
Fuzzers never really terminate, so it is not like you can plug it on a CI/CD system and wait for reports.
> The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all.
That's for one known crash. But otherwise it will be running 24/7 (across multiple VMs!) looking for issues.
More details here: https://github.com/google/syzkaller
In Bad Binder: Android In-the-Wild ExploitFor sure, implementing Linux is no easy task, and there is no magic bullet. For compatibility testing, we have extensive system call unit tests [1] and also run many open source test suites. Language runtime tests (e.g., Python, Go, etc) are particularly useful. We also perform continuous fuzzing with Syzkaller [2].
> how do you implement features that ostensibly require calls to the OS anyways?
gVisor's kernel is a user-space program, so it can and does make system calls to the host OS. Some examples:
* An application blocks trying to read(2) from a pipe. gVisor ultimately implements blocking by waiting on a Go channel. The Go runtime will ultimately implement this with a futex(2) call to the host OS.
* An application reads from a file that is ultimately backed by a file on the host (provided by the Gofer [3]). This will result in a prea
Read the rest
d(2) system call to the host.
The purpose here isn't to avoid the host completely (that's not possible), but to limit exposure to the host. gVisor can implement all the parts of Linux it does on a much smaller subset of host system calls. Anything we don't use is blocked by a second-level seccomp sandbox around the kernel. e.g., the kernel cannot make obscure system calls, or even open files or create sockets on the host (those operations are controlled by an external agent).
[1] https://github.com/google/gvisor/tree/master/test/syscalls/l...
[2] https://github.com/google/syzkaller
[3] https://gvisor.dev/docs/architecture_guide/overview/
If we could do this by waving a wand without downsides (e.g. all existing maintainers magically acquire Rust knowledge, etc.), yes it would be better. No question.
Seriously, people, you can find kernel bugs at will with kernel fuzzers like syzkaller from Google. Look at https://github.com/google/syzkaller/blob/master/docs/found_b... and weep.
In CompCert – A formally verified C compilerSyzkaller: unsupervised coverage-guided kernel fuzzer
1 points · Open discussionThis seems to be slides from a recent OpenBSD meetup where they were discussing the implementation of syzkaller[1], an open source tool from Google written in Go, to fuzz C kernels.
Then it lists 9 issues found in the OpenBSD kernel, including two[2][3] issues with kqueue.
Pretty cool stuff!
[1] https://github.com/google/syzkaller
[2] https://marc.info/?l=openbsd-cvs&m=153364550327224&w=2
[3] https://marc.info/?l=openbsd-cvs&m=152930020005260&w=2
In Fuzzing the OpenBSD Kernel [pdf]I don't understand this argument at all.
"Rust is not perfect, so it's basically the same as C"
The fact that "american fuzzy lop" and "syzkaller" have gone through the kernel and found dozens of use-after-free's (see https://github.com/google/syzkaller/blob/4bd70f/docs/linux/f...), shows that even incredibly carefully programmed C messes up in totally rote ways.
The basic cleanup code which is able to be exploited here would not be in an unsafe block if this were rust. In fact, because rust abstracts memory management out better, most of the cleanup code wouldn't exist at all.
Rust also allows better abstractions. For example, Rc<T> in rust is much easier to use without screwing up than the manually handled reference counters littered throughout the kernel. It seems obvious to me that numerous deadlocks in the kernel could be avoided by
Read the rest
not hand-rolling refcounting everywhere.
You're right that there's still the potential with rust for some code to compromise the safety of the entire kernel.
But with rust that's a subset of code, not practically every single line of the whole thing.
It seems to me like memory corruption/use-after-free/etc only being able to happen in a small fraction of code is better than it being able to happen anywhere.
Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.