Who Can Break the Chain?

For a SOHO router or IP camera, the answer to “who is responsible for vulnerability debt?” cannot be found by looking only at the logo on the device. The evidence points to a chain: an SoC vendor selects and packages a kernel baseline, an ODM/OEM integrator turns that platform into firmware, a branded vendor ships and supports the product, and communities, users, and regulators operate around the result. The final judgment is that the greatest leverage often sits upstream, where the baseline is chosen, but responsibility remains shared because downstream actors can inherit, question, replace, maintain, or disclose that choice.

That conclusion is stronger than a warning to “keep routers updated,” and narrower than a claim that every old kernel is exploitable. It asks what each security signal actually measures. A source-aware finding can indicate that a known vulnerable pattern remains in released firmware source. A kernel version can indicate age and lineage. An authenticated update channel can protect the delivery transaction. An end-of-life date can show that the normal upstream patch stream has closed. None of these signals answers all the others. A defensible assessment connects them without pretending they are interchangeable.

A credible upstream-debt claim has a chain, not a single signal

The causal model begins before the router or camera has a product name. An SoC vendor takes a mainstream Linux release, selects the parts relevant to a hardware platform, and supplies a software development kit with a stripped-down kernel, drivers, platform code, build systems, and configuration material. That SDK is an efficient starting point for downstream development because it is already connected to the chip. It is also the first visible place where a kernel line can become a default for products that the SoC vendor will not itself sell.

The next step is not automatic copying. An ODM/OEM integrator can preserve the SDK kernel or detach from it and select a newer supported line. The resulting firmware may contain substantial device-specific work, but the kernel baseline still carries the platform’s history. If the downstream image follows the SDK line, the old choice persists. If the image moves to another line, the integrator has taken on compatibility, validation, and maintenance work. The branded vendor then decides what firmware to accept, release, and promise to support. The important relationship is therefore not a simple arrow from “bad vendor” to “bad device.” It is a sequence in which a platform choice can narrow later options without erasing later decisions.

The study’s measurements show why that sequence matters at scale. Researchers identified 102 SoCs across 306 SOHO devices. Fifty-two SoCs were used by more than one device and together covered 70 percent of the devices. Five major SoC vendors accounted for 94.7 percent of the identified SoC set. These denominators belong to the study’s corpus and identified evidence, not to the entire router and camera market. Their significance is nevertheless clear: a relatively small set of upstream platform choices can recur across many downstream products.

A credible claim of inherited debt then needs more than a shared chip name. The analyst must connect the relevant source release and firmware image, identify the SDK-linked kernel region, and compare the kernel baseline with the version observed in the shipped binary. The study normalizes both versions to three components and treats a match as operational evidence that the firmware follows the SDK track. That is a useful test because it turns “the product uses the platform” into a measurable relationship. It is not a complete historical account of every alternative considered, every private patch, or every reason a team kept the line.

The observed relationship is still striking. In 174 cases where both signals could be recovered, only 12—6.8 percent—had a shipped kernel line newer than the SDK-associated line. The comparison reported 85 matching cases, 77 cases in which the binary line appeared older, and 12 newer cases. The narrow conclusion is that the shipped firmware usually preserved the SDK kernel track in this set of comparable artifacts. The stronger claim that every integrator was forced to do so is not supported by the version comparison alone.

The timing evidence adds a second link. For 40 of the 52 reused SoCs, the study could assess the corresponding kernel line’s upstream end-of-life status. Eleven of those 40 relied on lines that were already end of life, and eight of the eleven had SoC release years at least two years after the kernel’s end-of-life year. The representative examples make the ordering concrete: Linux 2.6.31 reached end of life in 2010 before an example AR9341 SoC release in 2011 and a device release in 2013; Linux 2.6.36 reached end of life in 2011 before an example BCM4709C0 release in 2015 and a device release in 2016.

The study uses SoC release year as a conservative proxy for when an SDK might have been introduced. Because an SDK could have appeared later than its chip, that proxy can understate the gap rather than exaggerate it. The result is best read as suspicious timing and support exposure, not as a precise timestamp for an unobserved engineering decision. Similarly, upstream end of life means that the mainstream kernel patch stream has ended.