The Linux stable kernel rules accept a backport only if the fix already exists in mainline, is obviously correct and tested, and is no bigger than 100 lines with context. Any team can copy that shape for its own backport policy: small, proven, upstream first.
What the rules say
The kernel documentation lists what a patch must satisfy to enter a stable tree. The core points, taken from the page itself:
- The fix, or an equivalent, must already exist in mainline.
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- It must fix a real problem that bothers people, such as a hang, data corruption or a real security issue.
- Theoretical issues are not enough unless an explanation of how the bug can be exploited is provided.
- Trivial changes such as spelling or whitespace are rejected.
The page also says that security patches should not be handled solely by the stable review process, and should follow the separate security bug procedure. That split matters: disclosure and backporting are two jobs.
Why upstream first prevents regressions
The document explains the reason. When someone asks for a fix to go into specific stable series, the fix must be applicable, submitted or already present in all newer stable trees still supported. Otherwise a user who upgrades from an older series to a newer one could lose a fix they had. Fix the newest line first, then walk backward.
A policy you can adapt
| Rule | What it protects against |
|---|---|
| Fix lands on the newest line first | Upgrade regressions |
| Backports must be small | Review errors and new bugs |
| A test comes with every backport | Silent behavior changes |
| Only real problems qualify | Churn on old branches |
| Security fixes follow a separate disclosure path | Leaking a fix before the advisory |
Steps to apply it
- Write down which release lines you still support. Fewer lines means better fixes.
- Set a size guide for backports. It does not have to be 100 lines, but have a number that triggers an extra reviewer.
- Require a link from every backport to the original commit. Git's cherry-pick command has an option that records the original commit in the message.
- Decide what happens when the backport is too large: either end support for that line, or give users an upgrade path.
- Test each supported line, not only the newest.
What not to copy blindly
The kernel has a large maintainer community and a long history. A small product team may not have the people to carry five branches. If you cannot test a branch properly, supporting it on paper is worse than announcing its end. Say which lines get security fixes and for how long.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a known fixed version is surfaced alongside the finding, the same information a backport decision starts from.
Safeguard scans dependencies and SBOMs so you can see which of your supported lines carry a vulnerable component, and shows fix versions where they exist. It can also open fix PRs through autonomous remediation, which is off by default. A free scan is at gold.safeguard.sh/scan.
Quick check
Is 100 lines a universal limit?
No. It is the Linux stable tree's own limit. Treat it as an example of a size guard, then pick a number that fits your codebase.
Should security fixes go through the normal backport queue?
The kernel documentation says they should follow the security bug procedure rather than rely only on the stable review process. Keep disclosure handling separate.
Sources
Last reviewed: 19 October 2026.
