Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dashboard/app: show full reproducer impact (don't stop at warn_on etc.) #5730

Open
tarasmadan opened this issue Jan 31, 2025 · 2 comments
Open

Comments

@tarasmadan
Copy link
Collaborator

tarasmadan commented Jan 31, 2025

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:

  1. Run reproduces on the kernel w/o panics and collect the full log.
  2. 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.

@tarasmadan
Copy link
Collaborator Author

tarasmadan commented Feb 11, 2025

We have 1664 upstream open bugs now. Grouping them by category:

  1. 324 WARNING
  2. 284 INFO
  3. 208 possible deadlock
  4. 196 KCSAN
  5. 180 KASAN
  6. 114 kernel panic
  7. 112 BUG
  8. 94 general protection fault
  9. 89 KMSAN
  10. 23 UBSAN
  11. 15 memory leak
  12. ~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.

@tarasmadan
Copy link
Collaborator Author

The second alternative target are the KASAN reads.
What looks more promising?:

  1. 180 KASAN reads -> XX KASAN writes conversion,
  2. 600 INFO+WARNING -> XX KASAN reads conversion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant