Network printers have been widely utilized to print various materials, but they still have security risks, caused by vulnerabilities that can be exploited for malicious attacks. Fuzzing is a popular testing technique that has found many vulnerabilities in various scenarios. However, existing fuzzing approaches are limited in network printer testing, due to important difficulties including unavailable source code of printer firmware, ineffective input generation, etc. In this paper, we design NetPuzz, a feedback-guided fuzzing framework of network printers for automated vulnerability detection. It performs fully black-box testing of network printing protocols, without the requirement of source code, reverse engineering or virtual execution of printer firmware. To achieve good results of vulnerability detection, NetPuzz utilizes two key techniques: (1) asequence-tree-based fuzzing approachthat generates effective input-packet sequences based on sequence tree mutation and printer response sequence guidance; (2) abisection-based strategythat extracts minimal PoC sequences from the original input-packet sequences triggering vulnerabilities. We use NetPuzz to test seven commercial network printers, and it finds 25 new and unique vulnerabilities, 23 of which have been assigned with CVE/CNVD IDs.

In Ethereum, DevP2P is the fundamental network-layer protocol set that supports consensus mechanisms, transaction propagation and smart contract execution. Due to the importance of DevP2P, its bugs can be exploited by the attacker to cause security problems like denial of service, leading to property loss on Ethereum. However, existing blockchain testing approaches focus on the bug detection of consensus and application layers, causing many serious DevP2P bugs to be missed. In fact, detecting DevP2P bugs has some key challenges, including how to generate effective inputs and how to detect complex bugs. This paper designs D2PFuzz, the first network-layer differential fuzzing approach of bug detection for Ethereum. It consists of two key techniques: (1) aquery-based fuzzing strategythat dynamically generates valid DevP2P messages according to network, chain and node state changes; and (2) amulti-node differential checking methodthat identifies important differences of DevP2P response messages from multiple nodes in the same blockchain to detect semantic bugs. We have evaluated D2PFuzz on five open-source and popular Ethereum node implementations, including Geth, Erigon, Reth, Besu and Nethermind. D2PFuzz in total finds 15 unique bugs, 12 of which are previously unknown. Compared to two state-of-the-art blockchain testing approaches including LOKI and Hive, D2PFuzz improves testing coverage by 3.7x and 21.6x, respectively, and finds 13 bugs missed by these approaches.

Due to limited test cases and execution scenarios, runtime testing often has insufficient code coverage and thus misses many real bugs. To tackle this problem, we propose a novel idea that static analysis of the triggered bug in runtime testing can help extend and detect extra bugs missed by runtime testing. Based on this idea, we develop a new approach named BESA, which can extend null-pointer dereferences found by runtime testing via static analysis. It first collects trace information about the triggered bug in runtime testing, by monitoring PoC (Proof of Concept) execution or analyzing existing failure log. Then, with this trace information, BESA uses a backward propagation analysis based on the call stack of the triggered bug, to effectively identify source variables propagating problematic value to the buggy variable. Finally, according to each source variable, BESA uses a summary-based alias-aware analysis to efficiently track target variables aliased with the buggy variable for detecting extra bugs. We have evaluated BESA on 25 known null-pointer dereferences found by runtime testing in four popular programs (SQLite, VIM, GPAC and Linux kernel). BESA finds 57 extra bugs, and 18 of them are new bugs that have been confirmed.

Robot Operating System (ROS) is very popular in robotic software development. To ease the process management of ROS programs, ROS provides a speciallifecyclemechanism that can conveniently manage the state of each running process, which often involves resource allocation, initialization, and release; and this mechanism has been widely used in real-world ROS programs. However, due to code concurrency of ROS programs, a lifecycle-related function is inevitably concurrently executed with other functions, introducing the security risk of dangerous concurrency bugs involving null-pointer dereference and use after free. Due to the non-determinism of thread scheduling, these concurrency bugs are difficult to find and reproduce. In this paper, we design and implement a new coverage-guided fuzzing framework named ROCF, which can effectively detect and reproduce lifecycle-related concurrency bugs in ROS programs, with two novel techniques. First, we propose alifecycle-aware fuzzing approachthat useslifecycle pair sequenceas a new coverage metric to effectively describe lifecycle-related thread interleavings, for input-mutation guidance of ROS concurrency fuzzing. Second, we propose aheuristic-based reproducing methodthat identifies minimal input sequences that can stably and efficiently reproduce the found concurrency bugs, with strategical input pruning and delay injection. We evaluate ROCF on eight popular robotic programs in ROS2, and it finds 32 new and real concurrency bugs, all of which have been confirmed by ROS developers, and 19 have been assigned CVE IDs.

An increasing number of robotic programs are implemented based on Robot Operating System (ROS), which provides many practical tools and libraries for robot development. To improve robot reliability and security, several recent approaches apply fuzzing to ROS programs for bug detection. However, these approaches still have some main limitations, including inefficient test case generation, ineffective program feedback and weak generality/automation.

The complexity of cryptographic APIs and developers' expertise gaps often leads to their improper use, seriously threatening information security. Existing cryptographic API misuse detection tools that rely on black/white-list methods require experts to manually establish detection rules. They struggle to dynamically update rules and scale to cover numerous unofficial cryptographic libraries. Furthermore, as these tools are primarily aimed at non-Go languages, they have limited applicability and accuracy in the Go ecosystem, which is extensively used for security-centric applications. To mitigate these challenges, we present Gopher, a novel cryptographic misuse detection framework, that excels in encapsulated API and cross-library detection. In this framework, we have designed CryDict to convert rules into unified and standardized constraints, capable of deriving new usage rules and elucidating implicit knowledge during scanning. Gopher leverages CryDict to create a logical separation between rule formulation and Detector detection, enabling dynamic updating of constraints and enhancing detection capabilities. This significantly improves the Gopher 's compatibility and scalability. Utilizing Gopher, we have conducted an extensive analysis of the Go ecosystem, examining 19,313 Go projects. In our rigorous testing, Gopher demonstrated a remarkable 98.9% accuracy rate and identified 64.1% of previously undetected misuses. This scrutiny has surfaced numerous hidden security vulnerabilities, and highlighted misuse tendencies across diverse project categories.

Real-world programs require error handling code to handle various kinds of possible errors. However, these errors just infrequently occur due to special conditions, so error handling code is difficult to test. Coverage-guided fuzzing and software fault injection (SFI) are two common techniques that can test error handling code, but they still have major limitations. Specifically, existing fuzzing approaches generate program inputs guided by code coverage, but many occasional errors (such as insufficient memory) are unrelated to inputs, and code coverage cannot effectively reflect the execution contexts of these errors; existing SFI approaches often inject single or random faults, without exploring fault space or using program feedback. In this paper, we propose a new fuzzing framework named EH-Fuzz, to effectively test error handling code. EH-Fuzz uses a context-sensitive SFI-based fuzzing approach to explore fault space and perform fault injection, guided by a new metric namederror coverage. We evaluate EH-Fuzz on 9 user-level programs and 6 kernel-level modules, and find 45 new real bugs, 31 of which have been confirmed and fixed. We compare EH-Fuzz to existing fuzzing approaches (including AFL, AFL++, Syzkaller, FIZZER and FIFUZZ), and EH-Fuzz finds many real bugs missed by these approaches with higher testing coverage.

The operating system (OS) is the cornerstone for computer systems. It manages hardware and provides fundamental service for user-level applications. Thus, detecting bugs in OSes is important to improve the reliability of computer systems. Static typestate analysis is a common technique for detecting various types of bugs, but it is often inaccurate or unscalable for large-size OS code, due to imprecision of identifying alias relationships as well as high costs of typestate tracking, path-feasibility validation, and inter-procedural analysis. In this article, 1 we present SPATA, a novel summary-based, alias-aware, and path-sensitive typestate analysis framework to detect OS bugs. To identify precise alias relationships in the OS code, SPATA performs a path-based alias analysis based on control-flow paths and access paths. With these alias relationships, SPATA reduces the costs of typestate tracking and path-feasibility validation, to accelerate path-sensitive typestate analysis for accurate bug detection. Moreover, SPATA uses an alias-summary-based analysis to accelerate inter-procedural bug detection, without time-consuming alias analysis across functions. We have evaluated SPATA on the Linux kernel and three popular IoT OSes, and it finds 651 real bugs with a false-positive rate of 18%. Besides, our alias-summary-based analysis achieves a 6.7x speedup in bug detection compared to non-summary-based analysis.

Operating system (OS) is the cornerstone for modern computer systems. It manages devices and provides fundamental service for user-level applications. Thus, detecting bugs in OSes is important to improve reliability and security of computer systems. Static typestate analysis is a common technique for detecting different types of bugs, but it is often inaccurate or unscalable for large-size OS code, due to imprecision of identifying alias relationships as well as high costs of typestate tracking and path-feasibility validation.

ROS is popular in robotic-software development, and thus detecting bugs in ROS programs is important for modern robots. Fuzzing is a promising technique of runtime testing. But existing fuzzing approaches are limited in testing ROS programs, due to neglecting ROS properties, such as multi-dimensional inputs, temporal features of inputs and the distributed node model. In this paper, we develop a new fuzzing framework named ROZZ, to effectively test ROS programs and detect bugs based on ROS properties. ROZZ has three key techniques: (1) a multi-dimensional generation method to generate test cases of ROS programs from multiple dimensions, including user data, configuration parameters and sensor messages; (2) a distributed branch coverage to describe the overall code coverage of multiple ROS nodes in the robot task; (3) a temporal mutation strategy to generate test cases with temporal information. We evaluate ROZZ on 10 common robotic programs in ROS2, and it finds 43 real bugs. 20 of these bugs have been confirmed and fixed by related ROS developers. We compare ROZZ to existing approaches for testing robotic programs, and ROZZ finds more bugs with higher code coverage.

Data races are often hard to detect in device drivers. According to our study of Linux driver patches that fix data races, about 39% of patches involve a pattern that we callinconsistent locking discipline. Specifically, if a variable is accessed within two concurrently executed functions, the sets of locks held around each access are disjoint, at least one of the locksets is non-empty, and at least one of the involved accesses is a write, then a data race may occur. In this paper, we present a hybrid static-dynamic analysis approach, named SDILP, to detect data races caused by inconsistent locking discipline in device drivers. SDILP has a dynamic lockset analysis to detect data races at runtime, and a static lockset analysis to detect more data races based on the dynamic-analysis results. It also performs a static taint analysis to reduce the number of variable accesses monitored by the dynamic analysis. Compared to our previous dynamic approach DILP (Chen et al., 2019), introducing static analysis allows SDILP to achieve better performance and find more data races. We evaluate SDILP on 12 drivers in Linux 5.4, and find 117 real data races, 50 of which have been confirmed by driver developers.

Modern robot systems use various software programs to autonomously perform different kinds of tasks. However, due to the risks of possible faults and errors, a robotic software program can inevitably crash in some cases, causing that the robot system fails to perform the current task. Thus, for robustness, the crashed program should be correctly recovered to continue the failed task. For this purpose, ROS provides a default restart method to automatically restart crashed programs. However, our case studies of typical ROS programs show that the restart method can perform incorrect crash recovery, and it can even cause the robot to perform dangerous behaviors, because this method loses the program’s important data that was stored before the crash and is used after recovery. To solve this problem, we develop a practical approach named RORY, to perform effective crash recovery of robot software programs in ROS. RORY uses a hybrid checkpoint-replay method, and it is generic to different ROS programs by considering ROS properties. We evaluate RORY on 6 common ROS programs, and show that RORY performs correct crash recovery in both virtual and realistic environments with modest overhead. The comparison experiments indicate that RORY outperforms the restart, checkpoint-alone and replay-alone methods.

For waiting, the Linux kernel offers both sleep-able and non-sleep operations. However, only non-sleep operations can be used in atomic context. Detecting the possibility of execution in atomic context requires a complete inter-procedural flow analysis, often involving function pointers. Developers may thus conservatively use non-sleep operations even outside of atomic context, which may damage system performance, as such operations unproductively monopolize the CPU. Until now, no systematic approach has been proposed to detect such conservative non-sleep (CNS) defects.

Device drivers remain a main source of runtime failures in operating systems. To detect bugs in device drivers, fuzzing has been commonly used in practice. However, a main limitation of existing fuzzing approaches is that they cannot effectively test error handling code. Indeed, these fuzzing approaches require effective inputs to cover target code, but much error handling code in drivers is triggered by occasional errors (such as insufficient memory and hardware malfunctions) that are not related to inputs. In this paper, based on software fault injection, we propose a new fuzzing approach named FIZZER, to test error handling code in device drivers. At compile time, FIZZER uses static analysis to recommend possible error sites that can trigger error handling code. During driver execution, by analyzing runtime information, it automatically fuzzes error-site sequences for fault injection to improve code coverage. We evaluate FIZZER on 18 device drivers in Linux 4.19, and in total find 22 real bugs. The code coverage is increased by over 15% compared to normal execution without fuzzing.

Data races are often hard to detect in device drivers, due to the non-determinism of concurrent execution. According to our study of Linux driver patches that fix data races, more than 38% of patches involve a pattern that we call inconsistent lock protection. Specifically, if a variable is accessed within two concurrently executed functions, the sets of locks held around each access are disjoint, at least one of the locksets is non-empty, and at least one of the involved accesses is a write, then a data race may occur.In this paper, we present a runtime analysis approach, named DILP, to detect data races caused by inconsistent lock protection in device drivers. By monitoring driver execution, DILP collects the information about runtime variable accesses and executed functions. Then after driver execution, DILP analyzes the collected information to detect and report data races caused by inconsistent lock protection. We evaluate DILP on 12 device drivers in Linux 4.16.9, and find 25 real data races.

Original device drivers are often passive in common operating systems, and they should correctly handle synchronization when concurrently invoked by multiple external threads. However, many concurrency bugs have occurred in drivers due to incautious synchronization. To solve concurrency problems, active driver is proposed to replace original passive driver. An active driver has its own thread and does not need to handle synchronization, thus the occurrence probability of many concurrency bugs can be effectively reduced. But previous approaches of active driver have some limitations. The biggest limitation is that original passive driver code needs to be manually rewritten. In this paper, we propose a practical approach, AutoPA, to automatically generate efficient active driver from original passive driver code. AutoPA uses function analysis and code instrumentation to perform automated driver generation, and it uses an improved active driver architecture to reduce performance degradation. We have evaluated AutoPA on 20 Linux drivers. The results show that AutoPA can automatically and successfully generate usable active drivers from original driver code. And generated active drivers can work normally with or without the synchronization primitives in original driver code. To check the effect of AutoPA on driver reliability, we perform fault injection testing on the generated active drivers, and find that all injected concurrency faults are well tolerated and the drivers can work normally. And the performance of generated active drivers is not obviously degraded compared to original passive drivers.

Atomic context is an execution state of the Linux kernel in which kernel code monopolizes a CPU core. In this state, the Linux kernel may only perform operations that cannot sleep, as otherwise a system hang or crash may occur. We refer to this kind of concurrency bug as a sleep-in-atomic-context (SAC) bug. In practice, SAC bugs are hard to find, as they do not cause problems in all executions. In this article, we propose a practical static approach named DSAC to effectively detect SAC bugs in the Linux kernel. DSAC uses three key techniques: (1) a summary-based analysis to identify the code that may be executed in atomic context, (2) a connection-based alias analysis to identify the set of functions referenced by a function pointer, and (3) a path-check method to filter out repeated reports and false bugs. We evaluate DSAC on Linux 4.17 and find 1,159 SAC bugs. We manually check all the bugs and find that 1,068 bugs are real. We have randomly selected 300 of the real bugs and sent them to kernel developers. 220 of these bugs have been confirmed, and 51 of our patches fixing 115 bugs have been applied.

Device drivers often suffer from much more bugs than the kernel, so testing device drivers becomes more and more important and necessary. In software testing, runtime tracing is an important technique to monitor real executing procedures of the program. Meanwhile, runtime information can also assist the programmer to make more accurate analysis of the program, like verifying the correctness of code execution and detecting bugs. However, due to kernel-mode execution and high complexity of kernel code, completely tracing drivers is hard, which causes real execution paths can not be clearly identified. In order to provide more powerful support for software testing of device drivers, we propose a method named Driver Trace, to do complete runtime tracing at the function level. Driver Trace utilizes instrumentation technique for runtime tracing, which is implemented based on LLVM compiler infrastructure. When the target driver works, Driver Trace records complete runtime information of function calls, like function names, return values and parameter pointers, and the information is recorded in a log file for future analysis. We have successfully implemented Driver Trace on 10 real device drivers in Linux 3.16.4 and made the evaluation as well. The experimental results show that Driver Trace provides an effective method of runtime tracing for device drivers with the modest overhead. Moreover, using an automated analysis of the runtime information recorded by Driver Trace, we also find 6 violations about resource usages in these 10 device drivers.

Drivers use kernel extension functions to manage devices, and there are often many rules on how they should be used. Among the rules, utilization of paired functions, which means that the functions must be called in pairs between two different functions, is extremely complex and important. However, such pairing rules are not well documented, and these rules can be easily violated by programmers when they unconsciously ignore or forget about them. Therefore it is useful to develop a tool to automatically extract paired functions in the kernel source and detect incorrect usages. We put forward a method called PairMiner in this paper. Heuristic and statistical mechanisms are adopted to associate with the special structure of drivers’ source code, to find out paired functions between relative operations, and then to detect violations with extracted paired functions. In the experiment evaluation, we have successfully found 1023 paired functions in Linux 3.10.10. The utility of PairMiner was evaluated by analyzing the source code of Linux 2.6.38 and 3.10.10. PairMiner located 265 bugs about paired function violations in 2.6.38 which have been fixed in 3.10.10. We also have identified 1994 paired function violations which have not yet been fixed in 3.10.10. We have reported some violations as potential bugs with emails to the developers, 27 developers have replied the emails and 20 bugs have been confirmed so far, 2 violations are confirmed as false positive.

Device drivers require system resources to control hardware and provide fundamental services for applications. The acquired resources must be explicitly released by drivers. Otherwise, these resources will never be reclaimed by the operating system, and they are not available for other programs any more, causing hard-to-find system problems. We study on Linux driver mailing lists, and find many applied patches handle improper resource-release operations, especially in error handling paths. In order to improve current resource management and avoid resource-release omissions in device drivers, we propose a novel approach named AutoRR, which can automatically and safely release resources based on specification-mining techniques. During execution, we maintain a resource-state table by recording the runtime information of function calls. If the driver fails to release acquired resources during execution, AutoRR will report violations and call corresponding releasing functions with the recorded runtime information to release acquired resources. To fully and safely release acquired resources, a dynamic analysis of resource dependency and allocation hierarchy is also performed, which can avoid dead resources and double frees. AutoRR works in both normal execution and error handling paths for reliable resource management. We implement AutoRR with LLVM, and evaluate it on 8 Ethernet drivers in Linux 3.17.2. The evaluation shows that the overhead of AutoRR is very low, and it has successfully fixed 18 detected resource-release omission violations without side effects. Our work shows a feasible way of using specification-mining results to avoid related violations.

Device drivers usually invoke functions to allocate resources for managing hardware devices and communicating with the kernel, and these resources should be released by functions when the work is finished. Thus allocating functions and releasing functions must be invoked in pairs. However, many developers ignore this vital rule, and some allocated resources are not released in time, which may cause resource related problems like deadlocks and memory leak. For improving the resource management of device drivers, we propose an approach named Pair Dyn to check these paired functions during runtime. When the driver runs, Pair Dyn records the runtime information of allocating functions such as key parameters and return value, and dynamically detects whether the relevant releasing functions are invoked to free allocated resources during runtime. Before the driver exits, Pair Dyn automatically attempts to invoke the related releasing functions which are lacked in runtime, in order to free the allocated resources of the operation system. We have implemented Pair Dyn with the LLVM compiler infrastructure, and make the evaluation with four real device drivers in Linux version 3.10.1. The experimental result shows that with the low extra overhead, Pair Dyn can provide effective runtime checking for allocate-release paired functions. Moreover, 9 potential bugs are found in the four drivers, which are all fixed automatically before exiting. Finally, no manual modification of the source code is needed with Pair Dyn.

Kernel extension functions are provided as interfaces for drivers to manage devices and resources, and there are many implicit rules about their usages. One of the most important rules is that many functions should be called in pairs. That is to say, when an error occurs in a function, the driver should call related functions to handle it and release the acquired resources before returning, and we name these functions between normal execution paths and error handling paths as paired functions. However, many developers are unaware of them, which causes lots of bugs. Therefore, it is highly significant to automatically extract paired functions and detect violations for drivers. This paper proposes an efficient tool named BP-Miner, which can extract paired functions from binary code of driver modules and detect violations for error handling in drivers with extracted paired functions. BP-Miner constructs control flow graph (CFG) based on basic blocks of binary code, and locates potential execution paths to extract paired functions. We have evaluated BP-Miner with Linux drivers 2.6.38 and 3.13.0-rc7. 76 bugs are reported by BP-Miner in 2.6.38 which have been fixed in the current latest version 3.13.0-rc7. BP-Miner spends about 90 minutes handling 3653 module files for 3.13.0-rc7, and 859 violations have been detected with 1167 extracted paired functions. As it works on the binary code, it can be utilized to check close-source drivers.