before the bisection. It's the best single candidate program. 2) During bisection, never drop the program. Commit: d7ca24bcef5a225f0b4bd0ee404b5650f871e61b https://github

base of bisection logs, you will find lots > > > of cases where bug types, functions don't match. Kernel crashes > > > differently even on the same revision. And

in a bisection, we must assume that the bug is not in > > > > > that commit, simply because we did not observe it anymore. > > > > > 2. the reproducer hit another

commit but bisection went wrong." (let's call it Y) is 7. So, X / Y = 2 / 7 = 0,28. 2/7 looks pretty good. This means 2/7 emails will be correct and add right people to CC rather than

the cause bisection fails to identify which commit introduce the vulnerability: > as PoCs are composed of system calls, and the implementation details of system calls with the

result in different manifestations - a function may be renamed/stack change across revisions But either way, see the next sentence. It will not allow you to do what you think it will

> The bisection results are also available on the dashboard, eg: > https://syzkaller.appspot.com/bug?id=02bde0600a225e8efa31bdce2e7f1b822542fef1 > > Bisection

of the bisection results are probably correct, and > 45 are probably incorrect. Ie, about 53% accuracy. > > It would be really helpful to improve this -- ideally by producing

a completely different bug: > > crash: BUG: MAX_STACK_TRACE_ENTRIES too low! > BUG: MAX_STACK_TRACE_ENTRIES too low! > > and for some reason decides that *that*