Loading learning content...
When you run uname -r on a Linux system, you see something like 6.6.14-200.fc39.x86_64. But what do these numbers mean? How long will this version be supported? Should you upgrade, and if so, to what?
Kernel versioning is not arbitrary—it encodes important information about stability, features, and support timelines. Understanding it helps you:
By the end of this page, you will understand: (1) The kernel version numbering scheme, (2) Stable, LTS, and mainline release types, (3) The kernel development and release cycle, (4) How distributions modify and package kernels, (5) Choosing the right kernel for different use cases, and (6) Tracking and applying security updates.
The Linux kernel uses a multi-component version numbering scheme. Let's dissect it:
Modern Version Format (Since 3.0, 2011):
MAJOR.MINOR.PATCH[-EXTRAVERSION]
│ │ │ │
│ │ │ └── Distribution/custom suffix
│ │ └── Patch/Stable release number
│ └── Release number (increments each release cycle)
└── Major version (rarely changes)
Example Breakdown:
| Version String | Component | Meaning |
|---|---|---|
6.6.14 | 6 | Major version |
6 | Release number (66th release in 6.x series) | |
14 | Patch level (14th stable update to 6.6) | |
6.6.14-200.fc39.x86_64 | -200.fc39.x86_64 | Fedora 39 build #200, for x86_64 |
Historical Context:
The version scheme has evolved over Linux's history:
| Era | Scheme | Example | Notes |
|---|---|---|---|
| 1991-1994 | 0.x | 0.99 | Pre-1.0 development |
| 1994-1996 | 1.x.y | 1.2.13 | Even minor = stable, odd = development |
| 1996-2003 | 2.x.y | 2.4.37 | Same even/odd stable/dev split |
| 2003-2011 | 2.6.x.y | 2.6.39.4 | Long-running 2.6 series |
| 2011-present | X.Y.Z | 6.6.14 | Major bumps are arbitrary |
The Great 3.0 Transition:
In 2011, Linus Torvalds declared that version 2.6.39 would be followed by 3.0 (not 2.6.40) to celebrate Linux's 20th anniversary. The major version bump was purely cosmetic—3.0 was not a revolutionary change from 2.6.39. Since then, major version increments happen when Linus feels the minor number is getting too large (3.19 → 4.0, 4.20 → 5.0, 5.19 → 6.0).
1234567891011121314151617181920212223242526272829303132
# Check running kernel version$ uname -r6.6.14-200.fc39.x86_64 # More detailed version info$ uname -aLinux hostname 6.6.14-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC ... # Check version defined in kernel source$ head -5 Makefile# SPDX-License-Identifier: GPL-2.0VERSION = 6PATCHLEVEL = 6SUBLEVEL = 14EXTRAVERSION = # Get version from kernel build$ make kernelversion6.6.14 $ make kernelrelease # Includes EXTRAVERSION6.6.14-custom # Version at runtime from /proc$ cat /proc/versionLinux version 6.6.14-200.fc39.x86_64 (mockbuild@...) (gcc (GCC) 13.2.1 20231011) #1 SMP PREEMPT_DYNAMIC ... # Distribution-specific version info$ cat /etc/os-release # Distribution info$ rpm -q kernel # RPM-based: installed kernel packages$ dpkg -l linux-image* # DEB-based: installed kernel packagesThe kernel Makefile has EXTRAVERSION (set by developers) and CONFIG_LOCALVERSION (set during config). Both append to the version string. Distributions use this to mark their builds (e.g., -200.fc39). For custom builds, set LOCALVERSION in config to identify your builds: CONFIG_LOCALVERSION="-mycompany".
The kernel project maintains several parallel release branches, each serving different needs:
| Type | Description | Support Duration | Use Case |
|---|---|---|---|
| Mainline | Linus's tree, latest features | ~2 weeks until next release | Developers, feature testing |
| Stable | Bug/security fixes to recent releases | ~3-6 months | Desktops, rolling distros |
| LTS (Long Term Support) | Extended maintenance for specific versions | 2-6 years | Servers, embedded, enterprise |
| linux-next | Integration tree for next release | Continuous development | Subsystem maintainers |
Mainline Releases:
The mainline kernel is maintained by Linus Torvalds and follows a regular release cycle (detailed in the next section). Each mainline release (e.g., 6.6, 6.7, 6.8) introduces new features, drivers, and improvements.
Stable Releases:
Once a mainline version is released, it becomes a "stable" branch maintained by Greg Kroah-Hartman and other stable maintainers. Stable releases (e.g., 6.6.1, 6.6.2, ..., 6.6.14) contain:
No new features are added to stable branches. Patches must be in mainline first, then backported.
LTS (Long Term Support) Releases:
Certain releases are designated for long-term maintenance. As of 2024, active LTS kernels include:
| Version | Released | End of Life | Status |
|---|---|---|---|
| 6.6 | Dec 2023 | Dec 2026 | Active |
| 6.1 | Dec 2022 | Dec 2026 | Active |
| 5.15 | Nov 2021 | Dec 2026 | Active |
| 5.10 | Dec 2020 | Dec 2026 | Active |
| 5.4 | Nov 2019 | Dec 2025 | Active |
| 4.19 | Oct 2018 | Dec 2024 | Ending |
LTS kernels receive security and critical bug fixes for multiple years, making them ideal for production systems requiring stability.
Visit https://kernel.org to see the current status of all kernel branches. The front page shows mainline, stable, and all active LTS versions with their latest patch levels. The 'longterm' entries are LTS kernels.
The Linux kernel follows a well-defined, time-based development cycle that has remained remarkably consistent for nearly two decades:
The Release Cycle (~10 weeks):
| Phase | Duration | Activities | What's Accepted |
|---|---|---|---|
| Merge Window | ~2 weeks | New features merged | Major changes, new drivers, APIs |
| rc1 | After merge window | First release candidate | Only bug fixes from here |
| rc2-rc7+ | ~1 week each | Stabilization | Bug fixes, regressions fixed |
| Final Release | When stable | X.Y released | Becomes stable branch |
Detailed Cycle Breakdown:
Week 1-2: Merge Window
Immediately after a release (e.g., 6.6), the "merge window" opens. During this intense two-week period:
Changes must be ready and tested before the merge window—it's not the time for last-minute coding.
Week 3+: Release Candidates (rc1 through rcN)
After closing the merge window, Linus releases 6.7-rc1. From this point:
Final Release
When Linus judges the kernel stable enough, he releases 6.7 (no rc suffix). The cycle restarts immediately with the next merge window for 6.8.
123456789101112131415161718192021
Example: Kernel 6.7 Development Cycle (actual dates) 2023-11-12: Linux 6.6 released2023-11-13: 6.7 merge window opens ├── Thousands of commits merged ├── New features from subsystem trees └── 15,000+ patches over 2 weeks 2023-11-26: Linux 6.7-rc1 released (merge window closes)2023-12-03: Linux 6.7-rc2 (bug fixes)2023-12-10: Linux 6.7-rc3 (bug fixes)2023-12-17: Linux 6.7-rc4 (bug fixes) └── Holiday slowdown expected2024-01-07: Linux 6.7-rc5 (bug fixes)2024-01-14: Linux 6.7-rc6 (bug fixes)2024-01-21: Linux 6.7-rc7 (getting stable) 2024-01-07: Linux 6.7 released2024-01-08: 6.8 merge window opens immediately Total cycle: ~9 weeks (typical: 8-10 weeks)Linus Torvalds' first rule: 'We don't break userspace.' If a kernel update breaks something that worked before, it's a regression and must be fixed or reverted. This policy ensures that upgrading kernels is generally safe. Report regressions to the regression mailing list!
The stable and LTS maintenance process ensures that security fixes and critical bugs are backported to supported kernel versions.
How Patches Enter Stable:
Patches don't go directly to stable trees. The process is:
Cc: stable@vger.kernel.org123456789101112131415161718
# Example of a commit marked for stable backport commit abc123def456789...Author: Developer <dev@example.org>Date: Mon Jan 15 10:30:00 2024 +0000 mm: fix use-after-free in page cache lookup A race condition in the page cache lookup could result in a use-after-free when pages are being reclaimed under memory pressure. This patch adds proper locking around the critical section. Reported-by: syzbot+deadbeef@syzkaller.appspot.org Fixes: 1234567890ab ("mm: optimize page cache lookup") Cc: stable@vger.kernel.org # <-- Marked for stable backport Signed-off-by: Developer <dev@example.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>Stable Release Frequency:
| Branch Type | Release Frequency | Typical Content |
|---|---|---|
| Current stable | ~Weekly | All applicable fixes |
| Recent LTS | ~Weekly to biweekly | Security + critical fixes |
| Older LTS | Monthly or as needed | Security fixes primarily |
Stable Kernel Rules (What Gets Backported):
The Stable Mailing List:
Stable kernel patches and release announcements go to stable@vger.kernel.org. Before each stable release, a review period allows testing:
Subject: [PATCH 6.6 001/150] mm: fix page cache race
This is the start of the stable review cycle for 6.6.15.
There are 150 patches in this series.
Please test and report any issues found.
The kernel.org team now publishes CVE information. Check https://www.kernel.org/category/releases.html and the linux-cve-announce mailing list. For each CVE, you can identify which stable branches have received the fix.
Most Linux users don't run upstream kernels directly. Instead, distributions package, configure, and patch kernels for their specific needs.
| Distribution | Kernel Strategy | Base Version | Update Policy |
|---|---|---|---|
| Ubuntu LTS | HWE (Hardware Enablement) | LTS + newer HWE | Security patches, point releases |
| Fedora | Near-upstream | Recent mainline | Track upstream closely |
| RHEL/CentOS | Heavily backported | Old base, new features backported | 10-year support lifecycle |
| Debian Stable | Frozen at release | LTS at release time | Security backports only |
| Arch Linux | Near-upstream | Latest stable | Rolling updates |
| SUSE Enterprise | Curated LTS | Selected LTS | Long-term backporting |
| Android | Heavily modified | LTS base + Android patches | Vendor-specific updates |
What Distributions Modify:
Configuration: Distributions choose default options optimized for their use case (desktop, server, cloud)
Backported Features: Enterprise distros may backport significant features from newer kernels
Out-of-Tree Drivers: Some include drivers not (yet) in mainline
Distribution-Specific Patches: Security hardening, branding, integration hooks
Build Configuration: Compiler options, debug flags, module policies
Example: RHEL Kernel Versioning:
# RHEL 9 kernel (really 5.14 base with massive backports)
$ uname -r
5.14.0-362.el9.x86_64
# │ │ └── RHEL build identifier
# │ └── RHEL patch level (362 internal updates)
# └── Base upstream version (actually heavily modified!)
# Compare features to upstream 5.14
# RHEL's 5.14 has features backported from 5.15, 5.16, ..., even 6.x
# The version number is misleading - it's more like a stable branch
If you replace your distribution kernel with an upstream kernel, you may void vendor support agreements. Enterprise support contracts typically require running distribution-supplied kernels. Always check your support terms before deploying custom kernels in production.
Selecting the appropriate kernel depends on your use case, hardware, and stability requirements:
| Use Case | Recommended Kernel | Rationale |
|---|---|---|
| Production Server | Distribution LTS or vendor kernel | Tested, supported, stable |
| Desktop (Stable) | Distribution default or LTS | Balance of features and stability |
| Desktop (Cutting Edge) | Latest stable or Fedora/Arch kernel | Newest features, latest drivers |
| Embedded Device | LTS kernel, custom config | Long support, minimal footprint |
| Kernel Development | Mainline or linux-next | Latest code, active development |
| Hardware Bring-up | Mainline + device tree patches | Newest driver support |
| Container Host | LTS with namespace/cgroup features | Stability + container features |
| Real-Time Systems | LTS + PREEMPT_RT patches | Deterministic latency |
Decision Factors:
1. Hardware Support
Newer kernels support newer hardware. If you have:
2. Stability Requirements
3. Support Lifecycle
| Need | Choice |
|---|---|
| Support for 6+ months | Latest stable or LTS |
| Support for 2-3 years | LTS kernel |
| Support for 5+ years | Enterprise distribution kernel |
4. Feature Requirements
Specific features may require minimum versions:
When upgrading kernels: (1) Always keep a working kernel to fall back to, (2) Test new kernels in non-production first, (3) For LTS jumps, read release notes for breaking changes, (4) Apply security updates within the same stable series immediately, (5) Plan major version upgrades around your maintenance windows.
Kernel security vulnerabilities are discovered regularly. Understanding how they're tracked and fixed is crucial for maintaining secure systems.
CVE Assignment for Kernel:
Since 2024, the kernel project self-assigns CVEs through the kernel.org CNA (CVE Numbering Authority). Previously, CVEs were assigned inconsistently. Now:
Example CVE Entry:
CVE-2024-1234
Affected: 5.10 - 6.7-rc4
Fixed in: 6.7-rc5, 6.6.5, 6.1.45, 5.15.135, 5.10.200
A use-after-free in the netfilter subsystem allows local
privilege escalation when processing crafted network packets.
CVSS Score: 7.8 (High)
123456789101112131415161718192021222324252627282930
# Check your kernel version$ uname -r6.1.32 # Check latest available for your branch at kernel.org$ curl -s https://www.kernel.org | grep -A1 '6.1'# Shows 6.1.75 or similar # You're 43 patch levels behind → update! # For distribution kernels, check package updates# Debian/Ubuntu:$ apt list --upgradable 2>/dev/null | grep linuxlinux-image-generic/jammy-security 5.15.0.92.82 amd64 [upgradable] $ sudo apt update && sudo apt upgrade$ sudo reboot # Kernel updates require reboot # Fedora/RHEL:$ dnf check-update kernel$ sudo dnf update kernel$ sudo reboot # Check for specific CVE# Visit: https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXXX# Or: https://www.cvedetails.com/ # Subscribe to security announcements# linux-cve-announce@lists.kernel.org# Your distribution's security mailing listFor systems that cannot reboot for security updates, kernel live patching (kpatch, kGraft, or Ubuntu Livepatch) allows applying critical security fixes without rebooting. This is typically an enterprise feature with additional costs and limitations—not all vulnerabilities can be live-patched.
When building custom kernels, properly setting version strings helps identify and manage your builds.
123456789101112131415161718192021222324252627282930313233343536373839
# The version string is composed of multiple parts:# VERSION.PATCHLEVEL.SUBLEVEL[-EXTRAVERSION][LOCALVERSION] # 1. View current version components$ head -5 MakefileVERSION = 6PATCHLEVEL = 6SUBLEVEL = 14EXTRAVERSION = # Can set manually in Makefile # 2. Set LOCALVERSION in config (recommended method)$ ./scripts/config --set-str CONFIG_LOCALVERSION "-mycompany-001" # Or interactively in menuconfig:# General setup → Local version - append to kernel release # 3. LOCALVERSION_AUTO adds git describe output$ ./scripts/config --enable CONFIG_LOCALVERSION_AUTO# Result: 6.6.14-mycompany-001-g1234abc (includes git hash) # 4. Build and verify$ make kernelrelease6.6.14-mycompany-001 $ make -j$(nproc)$ make modules_install INSTALL_MOD_PATH=/tmp/test$ ls /tmp/test/lib/modules/6.6.14-mycompany-001/ # 5. Use EXTRAVERSION in Makefile for development$ vim MakefileEXTRAVERSION = -rc1-custom# Result: 6.6.14-rc1-custom-mycompany-001 # Best practices:# - Use LOCALVERSION for organizational identification# - Enable LOCALVERSION_AUTO for git-based development# - Increment version suffix for each build# - Include meaningful identifiers (project, date, or build number)Version String Implications:
| Component | Effect | Module Path |
|---|---|---|
6.6.14 | Base version | /lib/modules/6.6.14/ |
6.6.14-custom | With LOCALVERSION | /lib/modules/6.6.14-custom/ |
6.6.14-custom-gABC123 | With LOCALVERSION_AUTO | /lib/modules/6.6.14-custom-gABC123/ |
Why Version Strings Matter:
/lib/modules/$(uname -r)/uname -rIf you install two kernels with identical version strings, modules will overwrite each other! Always use LOCALVERSION or build numbers to differentiate custom builds. Even development kernels need unique identifiers.
Module Complete:
With this page, you've completed Module 1: Linux Kernel Architecture. You now understand:
This foundation prepares you for deep exploration of Linux internals—process management, memory management, file systems, and networking in subsequent modules.
Congratulations! You've mastered Linux Kernel Architecture fundamentals—from architectural philosophy to practical compilation and versioning. This knowledge forms the foundation for understanding Linux internals at any depth.