When an Old Kernel Becomes the Default

For SOHO routers and IP cameras, an end-of-life kernel becomes a supply-chain problem when the same line moves from an SoC vendor’s SDK into shipped firmware instead of being replaced or deliberately maintained. This chapter follows that baseline through selection, inheritance, device release, and upstream support loss. The aim is to interpret the study’s version matches and timing evidence correctly: they show a strong pattern of reuse, but they do not by themselves reconstruct every engineering decision or prove that a particular device is exploitable.

The timing matters because “released later” and “built on newer software” are different claims. A router may receive a new firmware image after launch while retaining the kernel line supplied with its platform. A camera may reach the market after the upstream project has stopped maintaining that line. To see the difference, it helps to treat the kernel baseline as something with a lifecycle rather than as a label printed once on a product page.

The SDK is the earliest visible selection point

The study treats the SoC-vendor SDK as the earliest observable point at which a Linux kernel version is selected and then reused downstream. “Earliest observable” is important. The researchers can inspect the SDK-linked portion of a vendor’s source release and compare it with the kernel version extracted from the corresponding firmware binary. They cannot see every private meeting, contract, or discarded alternative that preceded the release. The SDK is therefore an evidence boundary: it is the first point in the available artifacts where the baseline can be identified with enough consistency to test inheritance.

To make the comparison, the study extracts the kernel baseline from the SDK-linked source region and the Linux version from the firmware image. It normalizes each to three version components and treats a match as evidence that the shipped firmware follows the SDK track. If the SDK source shows one line and the binary shows the same line, the match supports a claim of reuse. It does not prove that the SDK vendor forced the downstream choice, that no other kernel was considered, or that all code in the two artifacts is identical.

This operational definition is useful because it makes an otherwise vague phrase—“the vendor used the SDK”—testable. It also prevents a common leap from evidence to blame. A matching version establishes continuity across an artifact boundary. It does not identify the person or organization that decided continuity was acceptable. That judgment may have been embedded in a platform assumption, inherited by an integrator, or accepted during a product release review. The evidence can locate the path without assigning exclusive causality.

The comparison has three possible outcomes. The shipped line may match the SDK line, which is the clearest evidence of inheritance under the study’s test. It may be newer, which is consistent with downstream detachment or with another explanation that needs investigation.