Extended Stable (the -ckt kernel series)

The Canonical Kernel Team ("-ckt") provides extended stable support for certain versions of the Linux kernel, in the form of git branches available to the greater Linux community. These versions start from the last upstream stable release after upstream support ends.


The repository with stable linux branches is available at git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt (web interface: https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt). These are the relevant branches:


tracks the Linus master tree


stable tree for linux <version> release, final patches releases go to this


last release of stable tree for <version> release, with patches on top that are to be released with next <version> stable update


last release of stable tree for <version> release, with patches on top ready to be released with next <version> stable update, but which are on release candidate status (waiting any complaints or potential fixes before being released)

<version> is the linux stable series for which the Canonical Kernel Team provides stable patches. See the Version Matrix section for more information.

New Releases and Announcements

New releases of stable patches will be announced at kernel-team@lists.ubuntu.com, the linux kernel mailing list (lkml) and the stable mailing lists.

We will have a cadence of 1 to 3 weeks for new releases (that is, each 1/2/3 weeks if there are patches in the queue they will be put into a release candidate status, and if nothing is wrong after 2/3 days they will be released). For the release/maintenance process, see Maintenance below for more information.

For some releases, emails being sent for notifications or announcements should have the field X-Extended-Stable, an option for people that want to do filtering on received emails.


All patches for the -ckt stable releases should be submitted upstream, following the stable upstream acceptance rules (see Documentation/stable_kernel_rules.txt in the upstream kernel source tree for more information).

The Canonical Kernel Team should monitor and pick the relevant stable patches automatically once they are released with upstream stable. In case that not happens, or the change/patch is only applicable to one of the -ckt stable versions (in the case the patch isn't relevant to any of the current stable kernel versions being maintained by upstream, for example when a Cc: stable@kernel.org isn't applicable anymore), you can contact the team at kernel-team@lists.ubuntu.com requesting the patch to be applied. Of course the patch must conform to the stable upstream acceptance rules in the second case.

Version Matrix

This is the table with status of linux kernel versions that Canonical Kernel Team provided, provides or plans to provide with stable patches support

-ckt Kernel Version

Last Upstream Stable

CKT support window




December 2015 to July 2016 (now EOL)

Kamal Mostafa



May 2015 to July 2016 (now EOL)

Kamal Mostafa



October 2014 to April 2016 (now EOL)

Luis Henriques



April 2014 to April 2016 (now EOL)

Kamal Mostafa



December 2013 to August 2014 (now EOL)

Luis Henriques



May 2013 to August 2014 (now EOL)

Kamal Mostafa



November 2012 to March 2014 (now EOL)

Luis Henriques



after Ben Hutchings drops 3.2.y to April 2017


2.6.32, 2.6.33


2.6.32.y to April 2015 (now EOL)

Stefan Bader


We provide regular debian package builds of these stable releases at http://kernel.ubuntu.com/~kernel-ppa/mainline/.

Also, some builds usually are tested using our automated testing infrastructure, the results of the tests can be seen at http://kernel.ubuntu.com/testing/index.html


The maintenance process is more of interest for the person currently maintaining an stable tree, so it's not detailed here. If you are a maintainer, go to Stable Kernel Updates Maintenance. Generically, the process should be like this:

  1. Patches not yet included on stable version and marked for stable* are picked up from master Linus tree, and we try to apply them to the linux‑<version>.y‑queue branch:

    • Patches which apply cleanly, should be reviewed. If something shouldn't have been applied/added, discard/remove from the branch.
    • Patches which fails to apply, should be reviewed. If they are applicable to stable linux‑<version>.y, it must be fixed or a request sent out for help with backporting/fixing. The fixed version should be applied to the branch

    • Patches marked for stable but with a restriction for a specific kernel version, should only be applied if they are intended for stable linux‑<version>.y being maintained, in case the patch isn't applicable for it should be discarded.

  2. After the cadence period, push the patches from the linux‑<version>.y‑queue to the linux‑<version>.y‑review branch, and announce a review cycle on the mailing lists.

  3. After the review period, and with any problems found in review process fixed, push the patches from review to to linux‑<version>.y branch, close and tag the new release with simlar versioning as upstream (as close as possible, depending on the case), and rebase/sync both queue/review branches. Then announce the new release.

* marked for stable means the patch has Cc to stable, or was requested/should be included following the rules on the Contributing section. The same upstream stable rules apply.

Kernel/Dev/ExtendedStable (last edited 2016-07-13 18:58:46 by kamalmostafa)