1--- 2layout: default 3title: Bug fixing guidance 4nav_order: 6 5permalink: /advanced-topics/bug-fixing-guidance 6--- 7 8# Bug fixing guidance 9{: .no_toc} 10 11This page provides brief guidance on how to prioritise and fix bugs reported by 12OSS-Fuzz. 13 14- TOC 15{:toc} 16 17## Threat modelling 18In general the severity of an issue reported by OSS-Fuzz must be determined 19relative to the threat model of the project under analysis. Therefore, although 20the fuzzers OSS-Fuzz makes an effort into determining the severity of the bug 21the true severity of the bug depends on the threat model of the project. 22 23## Bug prioritisation 24 25### Security issues 26These are the top priority of solving. A label is attached to these on 27the OSS-Fuzz testcase page and you can also search up all of these on monorail 28using the search pattern `-Bug=security`. 29 30Issues of this kind include issues reported by Address Sanitizer, e.g. 31heap-based buffer overflows, stack-based buffer overflows and use-after-frees. 32 33### Functional issues and memory leaks 34These are issues that in general can tamper with the functionality of the 35application. The bugs that have highest priority in this case are those that 36can be easily triggered by an untrusted user of the project. 37 38### Timeouts and out-of-memory 39These are in general the least prioritised issues to solve. 40 41### Bug prioritisation of non C/C++ projects 42Currently there is no prioritisation of bugs in non C/C++ projects. As such, in 43this scenario it is crucial you do the analysis yourself relative to the threat 44model of your project. 45 46## Non-reproducible bugs 47OSS-Fuzz will report some bugs that are labeled `Reliably reproduces: NO` and 48these can be tricky to deal with. A non-reproducible bug is an issue that 49OSS-Fuzz did indeed discover, however, OSS-Fuzz is unable to reproduce the bug 50with `python infra/helper.py reproduce`. In general, our suggestion is to do 51analysis of the bug and determine whether there in fact is an issue. 52 53The non-reproducible bugs can be of varying nature. Some of these bugs will be 54due to some internal state of the target application being manipulated over the 55cause of several executions of the fuzzer function. This could be several 56hundreds or even thousands of executions and the bug may not be reproducible by 57a single fuzzer test-case, however, there is indeed a bug in the application. 58There are other reasons why bugs may be non-reproducible and in general any 59non-determinism introduced into the application can have an effect on this. 60 61In the case of non-reproducible bugs our advice is to put effort into analysing 62the potential bug and also assess whether this is due to some internal state 63that persists between each fuzz run. If that is indeed the case then we also 64suggest investigating whether the fuzzer can be written such that the internal 65state in the code will be reset between each fuzz run. 66 67## Should all reported issues be solved? 68It is reported by some project maintainers that fixing timeout issues reported 69by OSS-Fuzz can increase the complexity of the project’s source code. The 70result of this is that maintainers put effort into solving a timeout issue and 71the fix results in additional complexity of the project. The question is 72whether in a scenario like this if the overall result actually improves the 73state of the application. 74 75In order to answer this question we must assess the issue relative to the 76threat model. Following the timeout anecdote then some timing issues can have 77severe security implications. For example, if the timeout issue can cause 78manipulation of control-flow then the timing issue may be of high security 79severity. As such, it is difficult to say in the general case whether or not 80some bugs should not be solved, as it should be analysed and determined on a 81project-by-project basis. 82 83In the event that a bug is reported by OSS-Fuzz that is not relevant to 84security or reliability of the application then there may still be a point to 85fixing the bug. For example, if the issue is often run into by the fuzzer then 86the fuzzer may have difficulty exploring further code in the target, and thus 87fixing the bug will allow the fuzzer to explore further code. In this case some 88suggested examples of resolving the issue could be: 89* Perform a hot-patch that is only applied during fuzzer executions and does 90not overcomplicate the project’s code. 91* Patch the code of the fuzzer to avoid the timeout. For example, some fuzzers 92restrict the size of the input to avoid certain deep recursions or 93time-intensive loops. 94* Patch the code in the target despite complicating things. 95