Bug Levels


This is an attempt to summarize thinking on different types of bugs, how serious they are, and what an appropriate course of action to take is when they are discovered. It does not represent official policy of any kind.


All of these bugs require immediate, urgent action, and should be reported to the os/software maintainers asap, probably in private or semi-private channels to allow vulnerable systems to be patched prior to full public disclosure. The most serious bug possible is a bug which exploits the network stack of a machine that is not even running public services and allows arbitrary code to be run as the hostowner. The least serious bug in this category is remotely crashing a service such as ftpd which is not run by most users with publicly accessible machines. Any bug in this category needs a patch immediately, even if it is an ugly temporary hack.


These bugs are serious, but because they cannot be triggered remotely by completely untrusted parties, much less so. They should be patched, with a temporary fix if necessary, but they are not a cause for pulling the emergency eject. Once a user has an account on a box, it is generally hoped they will not behave maliciously, because forkbombs and memory exhaustion are always trivial to execute and very difficult to mitigate. Exploitation with non-arbitrary code means using an application to perform undesired tasks like read/write files which are not part of its intended operation. An example of a vital system service is a disk fileserver or ndb/cs.


These bugs are important, but do not require urgent patches. It is worth the time to make a careful patch suitable for permanent inclusion in the application or os. An example of kernel misbehavior would be a memory leak which grows slowly over a matter of weeks or which results in significantly degraded performance. Out of spec application behavior means it conflicts with the documentation or general standards of program behavior.


These bugs need to be fixed, but they do not render the application unusable. A memory leak which grows slowly, improperly handling error conditions which do not usually occur, thrashing the disk more than is necessary, or taking way too long to execute a simple task are bugs in this category. This category of bug is often found in applications with overall code quality problems and it may be worth the time to rework the problematic sections rather than simply patching the immediate bug.


These types of bugs are minor in comparison with more serious bugs. They may be worth addressing, but the risks of introducing new bugs while rewriting code should be taken into account. In addition, when there are known unfixed bugs which are more serious, addressing other issues may be a better use of time.