How to Measure Kernel Exposure Without Guessing
For a SOHO router or IP camera, the difficult vulnerability question is not how many Common Vulnerabilities and Exposures (CVEs) can be associated with the Linux version printed in its firmware. It is which vulnerable code was likely built into that device, under what configuration, and with what evidence that a fix is absent. This chapter focuses on that measurement problem so readers can interpret a large CVE count as a clue, not a verdict, and understand why source and build context produce a more precise—but still bounded—security judgment.
The distinction matters because the Linux kernel in a SOHO device is usually a selected and customized part of a broader release. A router does not need every subsystem found in a general-purpose Linux distribution. Its firmware may also contain fixes that were backported to an older version, or vendor changes that are not visible in a simple version comparison. The number associated with a kernel line can therefore describe the history of a much larger software universe than the code actually present in the router or camera.
A kernel version is a possibility list, not an inventory
The version-only method is attractive because it is straightforward. An analyst extracts a Linux version string from a firmware binary, looks up the CVEs known to affect that version, and treats the resulting set as the device’s potential kernel vulnerabilities. This method can be useful for triage. It is fast, reproducible, and able to identify a platform that deserves closer examination. Its weakness appears when a historical association is treated as proof that the corresponding code exists in the shipped product.
A version number identifies a position in the kernel’s release history. It does not fully identify the configuration used to build a particular firmware image. The image may omit a subsystem, compile a component differently, or include a fix that was applied without changing the visible version. In a stripped-down SOHO kernel, those differences are not edge cases; they are part of how the product is assembled. A CVE that applies to an optional networking component, a device-specific driver, or a subsystem absent from the image should not be counted in the same way as a flaw in code that the router actually built and uses.
The study’s comparison makes this problem concrete. Under version-string attribution, the average number of unique CVEs per device was 4,249 for D-Link, 3,884 for TP-Link, 4,318 for TRENDnet, 4,454 for NETGEAR, and 3,732 for Linksys. Under the study’s firmware-source inference, the corresponding averages were 43, 22, 23, 26, and 22. The authors report an average reduction of 99.8 percent when they move from version-based mapping to source-aware attribution.
The contrast is not evidence that the devices are nearly free of security problems. It is evidence that the two methods answer different questions. The first asks, roughly, “Which CVEs have ever been associated with this general kernel line?” The second asks, “Which known vulnerable patterns can be found in the source tree and build context associated with this firmware?” A broad answer to the first question can be inappropriate when presented as an answer to the second.
The identities of the resulting CVEs reinforce the point. The version-string list was dominated in its top ranks by issues in subsystems such as Open vSwitch and device-specific graphics drivers—components that may be absent from a lean router kernel. The source-based list instead surfaced issues in core IPv4 networking code, including an IGMP-handling vulnerability that is more plausibly relevant to a network device. The comparison does not prove that every networking issue is exploitable or that every graphics-related issue is irrelevant. It shows why knowing what the firmware instantiated changes the plausibility of the result.
A version string still has value, but its value is diagnostic rather than conclusive. It can identify the likely family of source to inspect, establish a rough age signal, and support comparisons among related images. It cannot, standing alone, establish that every CVE mapped to that line applies to the router. It also cannot show whether a vendor backported a fix while retaining the old version label. The responsible use of the shortcut is to let it trigger a deeper inquiry, not to let its output become a security score.
The shortcut can also fail in both directions. It can overcount by treating optional code as present, but it can understate what a vendor changed outside the assumptions of the version database. A version label is a compact identifier, not a manifest of configuration, patches, or interfaces. If two firmware images report the same kernel line, the label supports a broad comparison; it does not establish that their source trees, enabled components, or maintenance histories are the same. An analyst who wants to compare them must keep the shared version signal separate from the device-specific evidence.
That separation is especially important for an older kernel. Age is a useful reason to ask about support, but age alone is not a complete vulnerability finding. A vendor may have carried selected fixes forward, or a CVE may concern a component the product never built. Conversely, an old label should not be treated as proof that no security work occurred. The version-only method cannot resolve either possibility. It can tell the analyst where uncertainty begins.
Source and build context narrow the question
The source-aware method begins with the vendor’s GPL source release rather than treating the binary’s version string as the whole record. The analysis locates the Linux kernel subtree using several signals: recognizable kernel layout, files used to configure and build the kernel, and other evidence that the relevant source is actually present. It then applies CVE-specific semantic templates to the source. In plain terms, a template describes the structure of a known vulnerable code pattern and searches for that structure rather than merely searching for a version label.
The study uses Coccinelle as the semantic search and program-transformation tool, automated through cvehound and a public collection of CVE-specific templates. The important idea is not the tool name. It is the change in unit of analysis. Instead of asking whether a release number falls within a CVE’s historical range, the method asks whether the code pattern associated with that CVE appears in the kernel tree connected to the device’s firmware.
Build context makes that question more specific. A source tree can contain code that was not selected for the final image. Configuration and build artifacts help indicate which parts of the tree were intended to participate in the firmware. This does not make the inference perfect: build metadata can be incomplete, and the relationship between a public source tarball and a particular binary still needs to be established. It does, however, reduce the risk of counting every possible subsystem in a general kernel as though it were present in the router.
When an upstream fixing pattern is available, the study performs an additional check. A vulnerable-pattern match combined with the absence of the corresponding upstream fix is stronger evidence that the known vulnerable code remains in the analyzed source. The fix check is supporting evidence, not an independent guarantee. It helps distinguish an old-looking code fragment from one that appears not to have received the relevant upstream repair.
The order of these checks matters. First, the analyst needs a credible connection between the firmware image, the vendor’s source release, and the kernel subtree under inspection. Next, the source pattern must be interpreted in the context of the tree and its build evidence. Only then does the presence or absence of an upstream repair add useful weight. Skipping the linkage step would make a precise-looking template result misleading: it could describe a source release that was never used for the shipped image. The method is stronger because it combines several kinds of evidence, not because any one artifact is infallible.
The method also changes the shape of the question from “is this version vulnerable?” to “what would have to be true for this finding to apply?” The answer includes a matching source lineage, the relevant code pattern, no detected upstream repair, and enough build or configuration evidence to connect that code to the firmware. A missing link does not automatically clear the device; it lowers the confidence of that particular attribution and identifies the evidence that should be obtained next.
The two paths in the diagram should not be read as “bad method” versus “perfect method.” Version extraction supplies a broad screening path. Source and build analysis supplies a narrower inference path. Both end with uncertainty, but the uncertainty is different. The version path does not know enough about the instantiated code. The source path knows more about the released source but still does not observe every runtime condition or every private vendor modification.
That distinction also clarifies what counts as evidence of absence. If a version-based list names a vulnerability in a subsystem that the source and build context show is not included, the analyst has evidence against applying that particular mapping to the image. But if a source extract is incomplete, failure to find a pattern is not proof that the code does not exist elsewhere in the firmware. The strength of a negative conclusion depends on how complete and correctly matched the evidence is.
What the 99.8 percent reduction means—and what it does not
The reported reduction is striking because the numerator and denominator are not merely two estimates produced by the same inspection. They are the outputs of two different attribution models. The baseline maps version strings to all known CVEs associated with a general kernel line. The source-based method filters through actual source structure and build context, then uses semantic matches. The 99.8 percent figure therefore measures how much a broad version association can overstate the number of CVEs when it ignores what a customized SOHO kernel contains.
It also has a precise denominator. The table reports averages by vendor, not a universal average for all routers and cameras. The study examined a selected corpus of devices and the source releases available for its analysis. A reader should not take the D-Link, TP-Link, TRENDnet, NETGEAR, or Linksys figures and assign one of them to an unexamined product merely because the brand is similar. Nor should the 22-to-43 source-based range be read as a complete vulnerability count for each device. It covers the known kernel CVE patterns that the method could infer from the relevant evidence.
There is a second reason not to treat the smaller count as reassurance by itself. A source-level match can establish that a vulnerable pattern likely remains in the released kernel source and that the known upstream fix does not appear in that source when the fix template is available. It does not establish that an attacker can reach the code through the device’s exposed interfaces, that the exact binary was built from the analyzed source in every detail, or that another defense prevents exploitation. It also does not assess vulnerabilities outside the kernel patterns included in the method.
The study explicitly limits its patch inference to mainstream upstream fixes. A vendor may have applied a custom mitigation that does not match the upstream fixing pattern. The method cannot systematically detect such silent mitigations, even though the authors expect them to be relatively uncommon. “No upstream fix pattern found” should therefore be reported as a confidence-strengthening observation within the method’s scope, not as proof that no defense exists.
This is a useful place to distinguish a measurement result from a remediation decision. The result can justify asking the device vendor for a patch record, a source-to-binary explanation, or evidence about reachability. It does not dictate that a device must be discarded, nor does it justify publishing a fine-grained device-to-CVE map as though it were an exploit guide. The study’s value is in making the uncertainty actionable: a maintainer can investigate a particular code path, while an evaluator can avoid treating a broad count as a substitute for that investigation.
The strongest conclusion is therefore comparative. Source- and build-aware analysis is more faithful to a customized SOHO kernel than version-string mapping because it tests the code and context that the product actually appears to use. It is not a complete runtime security assessment. Its precision improves the question; it does not eliminate the need for judgment.
The same discipline applies to positive matches. “The vulnerable pattern is present in the analyzed source” is stronger than “the kernel version is historically associated with the CVE,” but it remains an inference about released artifacts. “The device is exploitable” is a further claim that would require evidence about the deployed binary, configuration, reachability, and relevant defenses. A dynamic analysis might change that conclusion; a vendor patch record might change it; a better source-to-binary match might change it. Good measurement makes clear what new evidence would move the claim in either direction.
This hierarchy is useful beyond this one study. When evaluating a router or camera, an analyst can ask four separate questions: what version does the image identify, which source and build evidence correspond to it, which known vulnerable patterns appear to remain, and what conditions would make those patterns reachable? The answers can be recorded at different confidence levels. A single CVE total cannot preserve those distinctions, and a single “secure” or “insecure” label cannot replace them.
The measurement problem also leads back to the supply chain. Once source analysis shows which kernel code is likely present, the next question is why that kernel line appears in the firmware and whether it was inherited from the platform SDK. A later chapter follows that baseline through version matches, end-of-life dates, and device release timelines. That step does not replace source analysis. It explains how the code arrived there, how widely the choice was reused, and whether downstream integration changed the line before the router or camera shipped.