You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Bug reproducer allows to reach some bug in the code satisfying its triggering condition.
Syzbot typically stops at the moment first oracle (sanitizer, WARN_ON etc.) reportes the problem.
The first oracle doesn't mean the only(or the most interesting) oracle.
The oracles have different reputation. For the community, KASAN: write ... is a much stronger prioritization signal than the WARNING: ....
According to our experience, memory safety bugs may be detected early by oracles like WARN_ON.
It makes sense to discover the whole reproducer impact collecting signals from all oracles.
Describe the solution you'd like
The alternatives are:
Run reproduces on the kernel w/o panics and collect the full log.
Setup more specialized instances (KASAN: write, KASAN: read) and correlate findings with general syzbot instances.
Additional context GREBE did similar thing. They collected information about the crash point and tried to reach it differently following the similar motivation, to prove higher impact of the existing finding.
The text was updated successfully, but these errors were encountered:
We have 1664 upstream open bugs now. Grouping them by category:
324 WARNING
284 INFO
208 possible deadlock
196 KCSAN
180 KASAN
114 kernel panic
112 BUG
94 general protection fault
89 KMSAN
23 UBSAN
15 memory leak
~20 other
600 INFO+WARNING are the main candidates for the deeper analysis.
The idea is to focus on the KASAN only instances and start using "kasan multi-shot" mode by syz-manager.
It will fuzz the same way it is fuzzing now.
Finding the reproducer we'll ignore INFO and WARNING messages (first run only?) and go deeper enabling KASAN to detect the consequences of the bug.
We'll continue to report the same INFO or WARNING but with additional details.
The amount of bugs found will not be changed.
Is your feature request related to a problem? Please describe.
Bug reproducer allows to reach some bug in the code satisfying its triggering condition.
Syzbot typically stops at the moment first oracle (sanitizer, WARN_ON etc.) reportes the problem.
The first oracle doesn't mean the only(or the most interesting) oracle.
The oracles have different reputation. For the community,
KASAN: write ...
is a much stronger prioritization signal than theWARNING: ...
.According to our experience, memory safety bugs may be detected early by oracles like WARN_ON.
It makes sense to discover the whole reproducer impact collecting signals from all oracles.
Describe the solution you'd like
The alternatives are:
Additional context
GREBE did similar thing. They collected information about the crash point and tried to reach it differently following the similar motivation, to prove higher impact of the existing finding.
The text was updated successfully, but these errors were encountered: