What the Evidence Says—and What It Does Not

CombiSan is no longer just an appealing architecture; it is an empirical claim about what a fuzzing campaign can observe and how much that observation costs. This chapter reads the paper's bug-finding campaigns, controlled comparisons, performance measurements, and deployment boundaries as one evidence chain. The aim is to decide what the reported results support, what they leave uncertain, and when a target's build or runtime conditions make the comparison inapplicable.

What the experiments establish

The strongest real-world result comes from a deliberately chosen sample. The authors selected ten latest-version software targets that OSS-Fuzz tested daily and that lacked MSan support. That choice serves the paper's compatibility question: these were projects for which UUM testing was difficult to obtain through the usual configuration. It also limits the result. The sample was not a random slice of all C and C++ software, and the researchers selected projects with substantial prior testing rather than estimating how common these bugs are in the wider ecosystem.

For each target, the authors ran five 72-hour fuzzing campaigns, starting from the public queues maintained by OSS-Fuzz. Across that experiment, CombiSan exposed 81 previously unknown bugs. The total included 17 addressability issues, 38 uses of uninitialized memory, 13 bugs in the other undefined-behavior categories enabled through UBSan, and 13 spontaneous crashes that were not tied to those sanitizer classes. The paper says the findings were confirmed by the relevant developers and describes private, responsible disclosure. The count is therefore meaningful evidence that the prototype can uncover bugs in real, already-fuzzed projects. It is not a claim that CombiSan will find 81 bugs in an arbitrary ten-project sample, or that the distribution of categories is a population statistic.

The project examples also show why workflow matters alongside detector scope. In Ghostscript, the tested setup reached a function-pointer type mismatch that caused every input to trigger undefined behavior. Treating that recurring report as a fresh stopping event would have prevented deeper exploration. CombiSan's policy recorded the first new UB and allowed known repetitions to complete, after which the campaign found three new UB bugs for the project. In OpenSC, the researchers first found six UUM bugs in one harness and then, after discussions with maintainers about the semantics of the project, tested six additional harnesses and found 15 more. Those cases do not prove that one report policy or one harness selection is always superior. They show that the useful observation boundary can be affected by target behavior and by which entry points a campaign exercises.

The controlled accuracy experiments answer a different question: can CombiSan recognize defects that the individual sanitizers recognize when the triggering inputs are available? In the selected Juliet cases, it detected the same bugs as the relevant ASan, MSan, and UBSan configurations on the bad tests. Some good tests produced initial CombiSan reports because they contained safe uninitialized loads; the accurate detector could discard those candidates.