Hector: Detecting Resource-Release Omission Faults in error-handling code for systems software

Abstract

Omitting resource-release operations in systems error handling code can lead to memory leaks, crashes, and deadlocks. Finding omission faults is challenging due to the difficulty of reproducing system errors, the diversity of system resources, and the lack of appropriate abstractions in the C language. To address these issues, numerous approaches have been proposed that globally scan a code base for common resource-release operations. Such macroscopic approaches are notorious for their many false positives, while also leaving many faults undetected. We propose a novel microscopic approach to finding resourcerelease omission faults in systems software. Rather than generalizing from the entire source code, our approach focuses on the error-handling code of each function. Using our tool, Hector, we have found over 370 faults in six systems software projects, including Linux, with a 23% false positive rate. Some of these faults allow an unprivileged malicious user to crash the entire system.

A Case for Static Analysis of Linux to Find Faults in Interrupt Request Handlers

“…This indicates that developing static checkers specific to validating the balance of the pairwise like Ref. [3] can effectively reduce debugging efforts during device driver developments. This is because the bug characteristics offer high coverages that dynamic testing cannot achieve.…”

“…3 and 4 suggests mistakes on IRQ releases happen on device drivers, i.e., loadable kernel modules in Linux kernel. An existing tool to detect intra-procedural resource-release omissions [3] shows the cases for initialization failures like in Fig. 3.…”

“…The problem of false positives in static analysis is out of the scope of this work, although more than a hundred happen. To find bugs more practically, we obviously need to reduce the number of false positives in future work as existing work already has [3].…”

“…A field study of Linux bugs in file systems [10] reveals that file system-specific bugs are dominant. Additionally, the sheer number of the previous work for finding unknown bug patterns ( [1], [3], [5], [6], [9], [11], [12], [13], etc.) suggests that new bug patterns will continue to show up in the future.…”

“…A good example of large-scale C code is an operating system such as Linux and Windows because these code bases are huge and complicated. In fact, static analysis is widely used to find bugs in Linux and Windows, especially in their device drivers [1], [2], [3], [4], [5], [6], [7], [8], [9].…”