When the test needs an authorization rule

A kernel operation can succeed, leave every allocation intact, and still be a security bug. The wrong caller may have been allowed to change an object it doesn’t own.

A memory sanitizer has no reason to complain about that outcome. To detect it, the test needs an expectation about authorization.

Input generation and bug detection are separate choices

Fuzzing generates and varies inputs. An oracle decides whether the resulting behavior is wrong. Crashes and sanitizer reports are common oracles, but fuzzing isn’t limited to them. Assertions, differential checks, and application-specific rules can detect failures that never crash.

The practical limitation is the test that’s been built. If its only success signal is a memory-safety report, an unauthorized operation may pass unnoticed. If its harness can’t initialize a device or describe an interface, that surface may receive little useful exercise.

Neither limitation means a whole subsystem has been exhausted or that a fuzzer could never reach it.

Look for the check that differs

Source review can help decide where to build a more specific test. One useful starting point is an operation whose neighboring implementations enforce a rule that it omits.

Consider network devices that can reference an underlay in another namespace. Checking privileges in the caller’s namespace may not establish permission over that underlay. The investigation needs to identify which object is affected and which security context owns it.

A VXLAN fix accepted upstream added a check for the underlay namespace. The patch is a concrete authorization example. It doesn’t establish that every similar-looking omission elsewhere is exploitable.

Turn the rule into an experiment

Write down the actors before constructing the reproducer: who owns the target, which privileges the caller has, and which action should be denied.

Then compare the same operation on vulnerable and fixed builds. A useful test shows the relevant action succeeding before the check and being rejected afterward. It should also show that a legitimately authorized caller can still perform the operation.

That last control matters. A change that breaks the feature for everyone can stop the test without enforcing the intended rule correctly.

A patch is a lead for finding variants

A security fix can reveal a missing invariant in sibling code. Search for the same operation, then inspect how each path protects it. Differences in caller permissions, object lifetime, or earlier checks may make a superficial match safe.

Before sending a report, check existing commits and maintainer queues. Variant hunting often reaches code other researchers are examining at the same time.

Use the methods together

Source reasoning helps formulate the condition to test. Fuzzing can explore inputs and sequences around it. A targeted oracle can distinguish permitted behavior from a boundary crossing. Maintainer review tests whether the explanation and fix fit the subsystem.

The opportunity is to improve those connections. A plausible missing check becomes useful research when the test demonstrates which caller can do what, and the patch restores the intended boundary.