The Linux kernel's stable tree accepts a fix only if it, or an equivalent, already exists in mainline, is obviously correct and tested, and is no bigger than 100 lines with context. It must fix a real bug, not a theoretical one. Security patches follow a separate private path. Any project that backports fixes can borrow these rules.
The acceptance rules
The kernel documentation lists what the stable tree takes and what it rejects. A change must meet all of these.
| Rule | What it means |
|---|---|
| Already upstream | The fix or an equivalent exists in mainline first |
| Obviously correct and tested | No guesses |
| Small | No bigger than 100 lines, with context |
| Follows patch rules | Same submission standards as mainline |
| Real bug | Fixes a problem like an oops, a hang, data corruption, a real security issue, a hardware quirk or a build error, or adds a device ID |
The document also lists what is turned away: no "this could be a problem" items such as a theoretical race condition unless an explanation of how the bug can be exploited is provided, and no trivial fixes with no benefit for users, such as spelling or whitespace cleanups.
Why fix upstream first
Requiring the fix in mainline first means older branches never carry code that the newest line lacks. The document adds a related rule: when you ask for a fix to go into specific stable series, make sure the fix or an equivalent is present in all newer stable trees still supported. This prevents a user from upgrading from one stable line to a newer one and losing a fix.
Security is a separate path
The page carries a note that security patches should not be handled solely by the stable review process, and should follow the kernel's security bug procedures. For unpublished vulnerabilities it advises using a different address in the stable tag, because mail to that address is not delivered anywhere, which reduces the chance of exposing the fix by accident.
What a smaller project can copy
You do not need a kernel sized process. A short list in your CONTRIBUTING file is enough.
- Fix the bug on the main branch first.
- Backport only fixes for real defects, with a short explanation of the user impact.
- Keep backports small. If a fix needs a refactor, say so and decide whether to skip that branch.
- Add a test that fails before the fix and passes after, on each branch.
- Backport to every newer supported branch before an older one.
- Handle undisclosed vulnerabilities privately, and do not reveal the security nature in public commit messages until disclosure.
- Publish which branches are supported, so users know whether a fix will reach them.
What consumers should read from this
If a project has rules like these, a backported fix is predictable. If it has none, ask before you depend on an old branch.
Quick check
Why is the size limit there?
Small changes are easier to review and carry less regression risk. The kernel sets the limit at 100 lines with context.
Are theoretical issues accepted?
Not without an explanation of how the bug can be exploited.
Is stable the route for security fixes?
Security patches are not handled solely by the stable review process. They follow the kernel's security bug procedures.
How Safeguard helps
Safeguard's SBOM and dependency scanning show which upstream versions you depend on, and reachability analysis helps you decide which advisories matter for your code. Compliance and evidence automation can record how you handled each one. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can run the free scan on a manifest to see where you stand.
Sources
- The Linux Kernel documentation, Everything you ever wanted to know about Linux stable releases: acceptance rules and submission options. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
