Linux kernel version history runs from the 0.01 release in 1991 to the 6.x and 7.x lines that now run most of the internet. The numbering is major.minor.patch, a new stable release ships every eight to ten weeks, and a handful of lines get tagged Long-Term Support and kept alive for years. The history reads well. Whether your own running kernel still gets security patches is the part that can actually hurt you. Run uname -r, then cross-reference kernel.org. If your line fell off the support list, you are running unpatched code, and that is a decision, not a footnote.

Last updated: 2026-07-18

You want a fast way to check kernel version history so you can confirm driver support, security patches, and software compatibility. I'll walk through terminal methods, from a quick uname call to listing installed images on Debian and Ubuntu, and explain what a string like 6.5.0-27-generic actually means. I'll also flag which command gives authoritative information and which ones only corroborate, so you can build a reliable audit trail for system changes.

How Linux kernel version numbering actually works

The scheme is major.minor.patch, and most people read too much into the first number. Take 6.5.0-27-generic. The 6 is the major line, the 5 is the minor release within it, and the trailing 0 is the stable patch level upstream. The -27 is your distro's own packaging revision, and generic names the flavor tuned for broad hardware.

Here is the part that trips people up: the major version carries no intrinsic meaning. Linux promises stable interfaces and behavior even across major bumps. A program built for 6.x is not expected to break on 7.x the way a semantic-versioning major bump would imply. The jump from 6.x to 7.x is bookkeeping, not an API break.

So why bump the major number at all? Because since the 3.x days, minor versions are capped around 20. When the minor climbs into the high teens, Linus rolls the major and resets. That is the whole rule. It is not semantic versioning, and treating it like semver will lead you to worry about the wrong upgrades.

The full release timeline, from 1991 to now

The short version: a hobby project in 1991 grew into the thing running most of the internet, with a numbering reset or two along the way. The 0.01 kernel dropped in 1991. The 1.0 release came in 1994. Version 2.0 in 1996 brought symmetric multiprocessing, and the long-lived 2.6 series ran for years before Linus jumped to 3.0 in 2011, mostly to drop a leading digit that had gotten tedious.

The 4.x and 5.x lines followed the same cadence. The 6.x era is where things sit now, and in the past three years the kernel has shipped versions 7.0, 6.12, and 6.6. As a concrete anchor, 6.5.0 released on August 27, 2023, and by 2026 the tree had rolled into the 7.x range.

Do not memorize this table as gospel. Version numbers move, and any list of "the newest kernel" in a blog is stale the day after a release. The timeline matters for context. Your patch status matters for security.

How do you check your kernel version right now?

Start with uname -r. It prints the running release string and nothing else, which is exactly what you want in a ticket or a script. Add uname -a when you also need the architecture, hostname, and build date to paste into an incident report.

On any systemd host, hostnamectl groups the Operating System and Kernel lines in one readable block. It is the friendly readout for audits. For build detail, cat /proc/version gives the compiler and build time straight from the kernel's own procfs, so it always matches the running binary. That makes it reliable when you suspect two commands disagree.

For boot-time proof, pull the line the kernel printed into the ring buffer:

sudo dmesg | grep "Linux version"

That tells you what actually loaded at boot, which is not always the newest image on disk.

On Debian and Ubuntu, list what is installed with dpkg -l | grep linux-image. Read the status codes. ii means installed and ready to boot; rc means removed but config files remain. The running kernel and the installed images are different questions. You can have a newer image on disk while you still run an older one because you have not rebooted. Always check both uname -r and the package list when something looks off. If you want to trim the dead ones, see the guide on removing unused kernel modules.

When the kernel was last updated, and how to verify it

Don't trust a cached web page for this, including this one. The mainline kernel gets point releases constantly, often several in a month, so whatever number you saw last week has probably already moved. The useful skill is verifying it live, not memorizing a date.

Go to the front page of kernel.org and read the release table. It lists mainline, stable, and each longterm line with its exact latest version and date. That is the primary source, updated the moment a release ships. For your own machine, what matters is whether your distro has pushed that patch, which is a separate feed.

Check your distro's side with the package manager. On Debian and Ubuntu, apt list --upgradable | grep linux-image shows a pending kernel update. The distro changelog tells you what the bump fixes. Run journalctl -k -b if you want to confirm what the current boot actually loaded. Here is what happens if you skip this: you read "latest kernel" in an article, assume you are covered, and stay two CVEs behind because your distro lagged upstream by a week.

The release cycle and how often a new version ships

A new stable kernel ships roughly every eight to ten weeks, and the rhythm is predictable enough to plan around. Each cycle opens with a two-week merge window where new features land in the tree. After that window closes, Linus tags -rc1.

Then come the release candidates, one per week, usually through -rc7 or so. Each -rc only takes fixes, not new features, so the tree stabilizes as the weeks pass. When it is calm enough, Linus cuts the final release and opens the next merge window. That is the entire loop, and it has run like a metronome for years.

Distributions run their own cadence on top of this. Enterprise vendors deliberately lag. Red Hat, for one, does not generally disclose future release schedules, so you follow their advisories rather than upstream's calendar. If you want to control when kernel bumps hit your fleet, set up scheduled kernel updates rather than reacting to each one.

Long-Term Support lines and when they hit end of life

Long-Term Support (LTS) kernels are older stable lines that keep getting backported security and bug fixes for years after the shiny releases move on. The lines currently maintained as LTS include 6.18, 6.12, 6.6, 6.1, 5.15, and 5.10. Each has its own end-of-life date, and those dates get extended or cut based on who is still using the line.

I won't print EOL dates here, because they change and a wrong date is worse than none. Read them off kernel.org's release table, where each longterm line shows its projected end of life next to it. That is the only place I trust for this.

The choice is simple. Pick an LTS line when your deployment horizon runs past a single release cycle, which is almost every server. Running past EOL is a security decision, not a version-history curiosity. Once a line hits end of life, no more patches ship, and every new vulnerability in that code stays open on your box forever. If you are stuck on an old line, plan the move with a proper kernel upgrade procedure instead of drifting.

What is Super Long-Term Support (SLTS)?

SLTS is a longer maintenance commitment run by the Civil Infrastructure Platform, a Linux Foundation project backed by industrial vendors. Where mainstream LTS lines get a few years, an SLTS line is maintained for a decade or more. That exists because power grids, rail signaling, and factory controllers cannot re-certify their software every two years.

It is a narrow tool. SLTS is right when you ship an embedded or industrial product with a support contract measured in decades and no realistic path to reboot into a new kernel line. For a general server it is the wrong pick. The maintenance is under-resourced compared to mainstream LTS, the backport pool is smaller, and you gain nothing over a normal LTS line you can actually upgrade on schedule. For most people reading this, SLTS is a spec-sheet feature you will never use.

Pulling the kernel source for your running version

Match the source to what uname -r reports, not to whatever is newest. First read your exact release string, then grab that tarball. Upstream sources live at kernel.org under the corresponding major directory, named like linux-6.5.tar.xz. For the stable point release, the linux-stable git tree carries a tag for every version, so you can check out the precise commit.

If you run a distro kernel with a -generic or -27 suffix, the upstream tarball is not the whole story. Your distro applies its own patches. On Debian and Ubuntu, apt source linux-image-$(uname -r) fetches the packaged source with those patches applied, which is what actually built your running kernel. That distinction matters when you are chasing a bug that only exists after a vendor backport.

Reading the source beats guessing every time. When a driver misbehaves and the forums all repeat the same wrong modprobe incantation, the answer is usually sitting in the module's source and the boot messages. Pull the code that matches your kernel, read it, and check dmesg. That tells you what is really happening instead of what someone assumed three years ago.

FAQ

Does a higher kernel major number mean my software will break?

No, and that is the common misread. The kernel keeps its interfaces stable across major bumps on purpose, so a jump like 6.x to 7.x is a renumber, not an API break. Userspace built for the old line is expected to keep running. If something does break after a kernel change, suspect a driver or module regression and boot the previous kernel from the GRUB menu to confirm it.

uname says one version but I just installed a newer kernel. Why?

Because uname -r reports the running kernel, and a freshly installed image does not become the running kernel until you reboot into it. The new image sits on disk with an ii status in dpkg -l | grep linux-image, ready but idle. Reboot, or if you want to swap without downtime look into live kernel patching. Until then, both answers are correct for their own question.

What does the "generic" or "virtual" suffix on an Ubuntu kernel mean?

It names the flavor, meaning which driver set and tuning the image ships with. generic targets broad hardware and is the default. The virtual flavor is the same as generic but excludes modules-extra, trimming drivers a virtual machine will never touch. Pick virtual for a VM guest to shave size, and stay on generic on bare metal where you might plug in real hardware.

How do I know if my kernel is still getting security patches?

Cross-reference two things. Read your version with uname -r, then check kernel.org's release table to see whether that line is still maintained or has passed its end of life. If your distro packages it, also watch that vendor's security advisories, since they backport fixes on their own timeline. A line off both lists gets no more patches, and that means new vulnerabilities stay open on the machine.

Which command is authoritative for the running kernel?

uname -r and cat /proc/version both read straight from the running kernel, so they are the ground truth for what is loaded now. dmesg | grep "Linux version" corroborates with the boot-time line. Package listings from dpkg -l tell you what is installed, not what is running. When two sources disagree, trust the procfs and uname, because they cannot report an image that is not actually executing.