The eBPF technology is widely used for many applications, including tracing, packet filtering, network usage monitoring, and so on. The versatility of eBPF allows the kernel’s capabilities to be extended without needing to modify source code or load kernel modules. However, the eBPF subsystem may introduce new bugs that could lead to crashes, data loss, and other issues that can negatively impact system stability, reliability, availability, security, and overall performance. Specifically, locking violations, which occur when locks are not used correctly, can lead to problems like deadlocks and system hangs. Since eBPF operates at the kernel level, errors here have far-reaching consequences.To tackle this issue, we present Spinner, a tool for detecting locking violations in the eBPF runtime. Spinner uses static analysis to (1) detect cases of context confusion where incorrect locking primitives are used in eBPF helper functions given their execution context, and (2) identify locks in helper functions that can be called recursively using nested eBPF programs. Both of these situations could result in deadlocks. So far, Spinner has identified 34 locking violation bugs in the eBPF subsystem in Linux, only 5 of which were previously found by Syzbot.

Over the past 7 years, Syzbot has fuzzed the Linux kernel day and night to report over 6,700 bugs, of which nearly 5,500 have been patched. While this is impressive, we have found that $25 \%$ of bugs take longer than 738 days to find. Moreover, we have found that current metrics commonly used, such as time-to-find and number of bugs found, are inaccurate in evaluating Syzbot since bugs often spend the majority of their lives hidden from the fuzzer. In this paper, we set out to better understand and quantify Syzbot’s performance and improvement in finding bugs. Our tool, SyzRetrospector, takes a different approach to evaluating Syzbot by finding the earliest that Syzbot was capable of finding a bug, and why that bug was revealed. We use SyzRetrospector on a large scale to analyze 695 bugs and find that $40 \%$ of bugs are hidden for more than 258 days before Syzbot is even able to find them. We further present findings on why bugs were revealed to Syzbot (i.e., their revealing factors), the effort required to reveal bugs, the trends in delays, and how the location of bugs affects these delays. We also provide key takeaways for improving Syzbot’s delays.