Summary

  • A Linux stable patch must clear an upstream and review test; long-term support asks a separate question about how long older code can be maintained.
  • Kernel.org describes that horizon as responsive to downstream demand and maintainer availability, so a projected end date is not a vendor support promise.

An older kernel can remain useful to a device long after its original release. That does not mean every proposed fix belongs in its stable branch, or that the branch will remain maintained for as long as a product is sold. Linux has two gates here, and mixing them turns a useful label into a false promise.

The first gate applies to an individual patch. The stable-kernel rules require that the fix, or an equivalent, already exist in mainline. It must be obviously correct and tested, fit within 100 lines including context, follow the patch-submission rules and address a real user problem or add a device ID. The examples include crashes, hangs, data corruption, real security problems, hardware quirks and build errors. The rules reject speculative problems without an explanation of how they can be exploited, as well as changes with no user benefit. Those limits make a backport easier to inspect and reduce the risk of introducing a new failure into a branch people already run. The stable rules spell out the criteria and the submission routes.

Passing that filter is not the same as skipping review. The documented process sends accepted candidates to a queue, invites review from developers and the relevant subsystem maintainer, and tests the result in release candidates. A reviewer can object and cause a patch to be dropped. Mainline-first is therefore a provenance requirement, not an automatic promise that every later kernel will receive the fix. The patch still has to apply meaningfully to the target series and survive review there.

The second gate is the life of the branch itself. Kernel.org describes long-term lines as older trees that receive important bug fixes, usually less frequently than active stable releases. Its release guidance says the choice reflects major features, commercial distribution needs, device-manufacturer demand, maintainer workload and availability. New long-term lines start with a projected end date that can be extended when enough industry interest helps support longer maintenance. The projection is explicitly not fixed. The page fetched for this article is stamped 25 February 2026; its policy language is useful, but its displayed release list is not an October 2026 snapshot. Kernel.org's release page is the source for the selection factors and projection policy.

This is where Greg Kroah-Hartman's role matters without making him the whole system. The Linux Foundation identifies him as a Fellow, a maintainer of the Linux stable branch and several subsystems. The kernel development process document names Greg and Sasha Levin as the stable team, while noting that relevant maintainers and reviewers participate in patch review. In a 2018 interview, Greg recalled volunteering when stable kernel releases began in 2005. He said the number of simultaneous trees he maintained grew and connected that work with keeping devices in the field more secure. That is his retrospective, not a current count of branches or proof that he alone selects each long-term line. The Linux Foundation profile, the kernel development process and Greg's interview establish the role and its limits.

For an operator, the distinction changes what a support label can tell you. A kernel.org long-term branch is a community maintenance line. A distribution may ship a kernel based on it, carry additional changes, or maintain another kernel on its own schedule. Kernel.org directs users of distribution builds to their distribution's support channel and says kernel developers may not support those builds. An operator therefore has to identify who maintains the exact kernel in the deployed image, what security and regression path applies, and whether the vendor's commitment reaches the product's operating horizon. The LTS label alone answers none of those contractual questions. Kernel.org's FAQ and release page distinguish these support surfaces.

The economic mechanism is plain but easy to hide behind a version number. Every additional line that remains supported creates work: someone must assess proposed fixes, check backports, test releases and respond when a regression appears. The public pages do not publish the hours or cost of that work. They do show that downstream needs and maintainer availability affect which lines receive longer attention. Industry demand can help justify the effort; it cannot eliminate the need for people to do it.

Heng Lu's Note 64 offers a useful analytical test: a coordination document can describe a future state, but it does not make that state operational by itself. Linux is not presented here as a system designed under that note. Applied only as a lens, the distinction helps explain why “long-term” and a projected end date are not self-enforcing warranties. They describe a support arrangement that must continue to be adopted and maintained. Note 64 is an analytical reference, not evidence about kernel policy.

Analysis

The two gates allocate risk at different levels. Patch rules limit what may enter an existing branch; long-term selection limits how many old branches the maintenance community can keep carrying. A stricter patch filter cannot create years of staff capacity, and strong industry demand cannot make an unreviewed backport safe. The practical commitment exists only where both the fix and the maintenance line remain viable.

That makes support horizons sensitive to a changing coalition. Device makers may need an older kernel for hardware already in the field; distributions may need a stable base for a release; maintainers must have time to review and test the work. Public sources do not say how those contributions are divided or quantify the bargaining power of any one participant. They do show that support duration is shaped by demand and available labor, rather than by the age of a version number alone.

Sources