Description
I want to set up a local kernel fuzzing environment using Syzkaller [0] to better understand its architecture. My focus will be on input mutation logic, subsystem modeling, and how coverage descriptions are currently structured. I'm particularly interested in rapidly evolving subsystems like io_uring and BPF to see where fuzzing descriptions might be incomplete or outdated. I'd like to write at least one custom syzlang definition to better understand the process and identify potential coverage improvements.
Goals
- Infrastructure: Build and tune a self-hosted fuzzing setup optimized for kernel testing on my home server.
- Research: Understand how Syzkaller generates and mutates inputs, how subsystem descriptions are structured in syzlang, and where improvements or new descriptions could help expand coverage in undertested areas.
- Coverage Work: Write at least one custom Syzkaller description to reach currently untested kernel paths, with documentation of what gap it fills.
- Crash Analysis (if any occur): Triage and analyze any unique crashes discovered during the project.
Stretch Goals (Time Permitting)
I have a backlog of previously triaged CVEs. While Syzkaller runs, I'd like to attempt exploiting at least one of them. My focus would primarily be privilege escalation exploits, though I have several CVEs with some possible unusual attack paths worth investigating.
Resources
[0] https://github.com/google/syzkaller
Looking for hackers with the skills:
Nothing? Add some keywords!
This project is part of:
Hack Week 25
Activity
Comments
-
17 days ago by yosun | Reply
I used Trinity to fuzz test the kernel several years ago and found it hard to reproduce the issue. And Syzkaller seems to support it well, I'd also like to take a look at it. If I have some findings, I'll share them with you.
Similar Projects
This project is one of its kind!