syz-manager: per-syscall limits too restrictive
- Dominant language
- Go
- Stars
- 6.3k
- Forks
- 1.4k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 75
Description
**Describe the bug**
`minimizeCorpusLocked()` in `syz-manager/manager.go` contains hardcoded limits for rejecting corpus entries if a given syscall occurs too frequently in the corpus. According to the code comments, this is a defensive mechanism against "corpus explosions".
We think the current implementation of this heuristic actively holds back syzkaller performance on `io_uring` related syscalls on Linux. By design, `io_uring` contains a lot of complexity and code diversity behind few individual real and artificial syzkaller syscalls.
Affected:
* `io_uring_setup()`
* `io_uring_enter()`
* `syz_io_uring_setup()`
* `syz_io_uring_submit()`
The `io_uring_register()` syscall is potentially less affected, since it has explicit sub-variants (`io_uring_register$ABC`).
Note that this problem gets worse over time as more functionality is reachable via `io_uring` on newer kernels and expressed in syzlang grammar, because more unique corpus entries will call into the same syscalls.
**To Reproduce**
During local syzkaller fuzzing, we ran into the "coverage for X has saturated, not accepting more inputs" warning that signals rejections by this heuristic, defined [here](https://github.com/google/syzkaller/blob/1c2ff3f985f46c14d19fdadaf02516787d3f5449/syz-manager/manager.go#L1143C16-L1143C72).
**Expected behavior**
Fuzzer behavior on complex syscalls is not excessively restricted, or known complex syscalls are allowlisted into a second tier of restrictions.
**Additional context**
Issue observed during an X41 D-Sec GmbH research project into io_uring Linux kernel security, sponsored by OSTIF.
Contributor guide
Research direction
Start in syz-manager/manager.go at minimizeCorpusLocked(), especially the hardcoded limits linked near line 1143. Reproduce the "coverage for X has saturated, not accepting more inputs" warning during local syzkaller fuzzing and compare behavior for the listed io_uring syscalls. Done means complex syscalls are no longer excessively restricted while the corpus-explosion defense remains effective.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- operating-systems, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100