Mining and checking paired functions in device drivers using characteristic fault injection

Fuzzing Error Handling Code in Device Drivers Based on Software Fault Injection

“…An important problem here is how to inject faults to effectively cover as much error handling code as possible. Previous SFI-based approaches for device drivers often inject random faults [21] or perform single fault injection [16], but these strategies still miss much error handling code. To solve this problem, we propose to "fuzz" injected faults according to the runtime information of the driver.…”

“…Note that the mutation method only mutates the executed error sites. Indeed, most segments of error handling code require the failure of only single error site to trigger, and then make the driver abnormally exit without executing other error sites [16]. Thus, only mutating executed error sites can avoid generating many unnecessary error-site sequences.…”

“…To reduce manual work, the error-site analyzer performs static analysis to recommend possible error sites, from which the user should select realistic ones. This static analysis focuses on recommending function calls that can fail as error sites, as a large part of error handling code in drivers is triggered by bad function return values [16].…”

“…Some SFI-based approaches [14]- [16], [21], [50], [51] can test kernel-level device drivers. Mendona et al [21] propose a robustness-testing approach for Windows device drivers.…”

“…In this way, SFI can effectively cover error handling code at runtime. Some SFI-based approaches [13]- [16] have shown promising results in testing error handling code and finding bugs in drivers.…”