 |
This page describes a study of the backtrace provided by the kernel in case of crash. We focus in this study o crashes due to invalid pointer dereferences. |
Methodology
Since, we have performed code mutations to remove error handling code and provoke crashes during fault injections on slab allocations, the analysis of the oops report consists on assessing the difficulty to deduce the mutation.
-
the tools : gdb and addr2line are useful utilities for pinpointing point of crashes. The dereference point beeing marked in the oops report, the difficulty of finding it, depends on whether the crash occured within the kernel or within the service. When it occurs within the service, addr2line alone is sufficient.
-
the principles : The cause/origin of the crash being the most important information for fixing a bug, we consider that it should somehow be readily deducible from the oops report.
Examples
We show here a few examples of crashes using different services :
2.1. Bluetooth USB
We performed a mutation of the usage of hci_alloc_dev in btusb driver by removing error handling code. See the patch in btusb.html. The crash report that we obtained indicates that the crash occurs within the service. Though it does not mention any call to hci_alloc_dev, the developer can easily figure out that the derereferenced pointer value was obtained as a result of a call to this function.
We have also provoked a crash by ignoring the failure of usb_alloc_urb in function btusb_submit_intr_urb as described by the patch in btusb2.html. The crash report shows that the crash occured in another function usb_fill_intr_urb which dereferenced an invalid argument without check.
2.2. ISOFS filesystem
For the isofs filesystem, we have selected a mutation in a function, isofs_alloc_inode that is never directly called by the service code itself. The patch in isofs.html. The crash report indicates that the dereference occured outside the service. Moreover, to understand the origin of the problem, the developer must correlate kernel and service code and follow a pointer function definition and assignment in the kernel and isofs.
2.3. NFS filesystem
Another complex example : The crash report in crash_nfs.html was obtained after mutating code in the file read.c of the nfs filesystem directory. Using this report, the developer needs to go through several functions in the kernel before considering the possibility that the mutation concerns mempool_alloc called by readdata_alloc which is defined by nfs code. See the original mutation here.