What It Means to Find a Bug Before It Fails

OS-Sanitizer gives a qualified yes to the question at the heart of this series: benign runtime behavior can reveal a latent defect before the software produces a visible failure. OS-Sanitizer is the subject—not eBPF in the abstract—and the important judgment is how its eBPF vantage point connects Linux application behavior with ownership, privilege, timing, and downstream use. The evidence supports dynamic defect inference as a useful addition to software testing, provided its reports are treated as contextual leads, its costs are measured on the actual workload, and its conclusions are validated by people and other tools.

The answer is yes, but it is an inference

A failure-based test waits for a counterexample. It supplies an input or action, observes an invalid result, and gives the team a concrete behavior to reproduce. OS-Sanitizer operates earlier. It observes a behavior that may be harmless in the current execution but resembles a defect pattern when the surrounding context is included.

That is a real expansion of what dynamic testing can ask. A path operation may look ordinary until the system reveals that an intermediate component can be changed by another user while a privileged process relies on it. A memory-permission pattern may be intentional for a just-in-time compiler while also identifying a complex, under-tested region. A library call may be safe for its original caller and become consequential when a container-management tool uses it across a privilege boundary.

In each case, the runtime event is evidence of a relationship. OS-Sanitizer does not conjure a vulnerability from an isolated function name. It uses eBPF to observe selected facts from a running Linux system, combines them with heuristics, and sends a suspicion to userspace for interpretation. The core result is a change in timing: the system can raise a question before a failure makes the answer unavoidable.

The qualification is equally important. A heuristic report is not a proof that the application has failed, and a quiet monitor is not proof that it has no latent defects. The method can infer only from the events, contexts, and behavior classes its passes can observe. Its strength is earlier and richer investigation, not universal certainty.

What the study establishes

The supplied study provides evidence at several levels, and they should not be mixed.

At the level of discovery, the authors report 12 defects found directly during development and more than 30 additional defects uncovered by following behavioral code smells. The cases include a long-standing stack-buffer-overflow risk in a configuration library, filesystem behavior that became dangerous when inherited by privileged container software, and a user-owned file executed with elevated authority. These examples show that the method can expose issues in dependencies and downstream integrations, not only in the application whose process happens to be observed.

At the level of investigative value, the cases show a repeatable pattern. A report identifies a code region or a system relationship. Investigators then use source review, symbolization, reproduction, fuzzing, or additional testing to decide what the signal means. In one memory-safety case, the report guided a fuzzer toward a difficult-to-trigger region and the follow-up work found more bugs. In the just-in-time compilation case, a warning about RWX memory led to testing infrastructure for an under-tested component, which uncovered further security-relevant and correctness issues. These follow-up findings were not all direct outputs of the initial heuristic. The evidence supports a more precise claim: the heuristic improved where investigators looked.

At the level of system design, eBPF supplies a useful position for this work. It can observe selected user-space and kernel-space events, preserve relationships across multiple events, and operate without recompiling or modifying the target applications. That matters when the defect’s meaning lies at a system boundary. A library call in user space may not reveal the ownership and permission context that the kernel sees. A kernel event alone may not identify the application path that initiated it. OS-Sanitizer’s passes use both perspectives to make the relationship legible.

At the level of performance, the study supports conditional feasibility.