The Linux kernel is the core program of a Linux operating system: it runs with full hardware privileges and manages processes, memory, devices, file systems, networking and security on behalf of every other program. Applications never touch hardware directly; they request services from the kernel through system calls.
Among Linux fundamentals, the kernel is what the word “Linux” strictly refers to. Created by Linus Torvalds in 1991 and licensed under the GNU General Public License version 2, it is combined with GNU tools, a C library, an init system and package management to form distributions such as Debian, Ubuntu, Fedora and Arch Linux. The same kernel runs on smartphones, servers, routers, supercomputers and embedded devices.
How the Linux kernel is structured
Linux is a monolithic kernel: its core subsystems run together in one privileged address space called kernel space, which keeps internal calls fast. It is also modular, because drivers and features can be compiled as loadable kernel modules and inserted or removed at runtime with tools such as modprobe.
The table lists the major subsystems and what each one is responsible for.
| Subsystem | Responsibility | Visible to users as |
|---|---|---|
| Process scheduler | Shares CPU time among tasks | nice values, CPU affinity |
| Memory management | Virtual memory, paging, page cache | free output, swap usage |
| Virtual file system | Common interface over ext4, XFS, Btrfs and others | Mount points, /proc, /sys |
| Networking stack | TCP/IP, routing, packet filtering | ip commands, nftables rules |
| Device drivers | Control disks, GPUs, network cards | Entries under /dev, lsmod |
| Security modules | Mandatory access control frameworks | SELinux, AppArmor policies |
User space, kernel space and system calls
The CPU enforces a boundary between user mode and kernel mode. A program that wants to read a file executes a system call such as read, the processor switches into kernel mode, the kernel validates the request and performs it, and control returns to the program. Linux on x86-64 provides several hundred system calls, and the kernel maintainers treat the user-space interface as a strict contract: a change must never break existing user programs.
Besides system calls, the kernel exposes state through pseudo file systems: /proc describes processes and tunables, and /sys describes devices and drivers. Parameters such as network buffer sizes are adjusted at runtime through sysctl. Modern kernels also support eBPF, which loads verified programs into the kernel for tracing, networking and security without writing a module.
Kernel versions and release types
Mainline development follows a fixed rhythm: new features enter only during the merge window, weekly release candidates then stabilize the code, and a new version appears about every nine to ten weeks. Because most systems value stability, distributions usually ship a long-term support kernel or maintain their own patched branch.
| Release line | Maintained for | Typical users |
|---|---|---|
| Mainline | Until the next release | Kernel developers, testers |
| Stable | A few months | Rolling distributions such as Arch Linux and Fedora |
| Longterm (LTS) | Several years | Servers, embedded and Android devices |
| Distribution kernels | Life of the distribution release | Debian, Ubuntu and enterprise systems |
| Civil infrastructure kernels | Ten years or more | Industrial and infrastructure equipment |
The version string from uname -r, such as 6.6.52-generic, shows the major and minor version, the stable patch level and a distribution suffix. Distribution kernels often backport fixes, so a lower version number does not necessarily mean missing security patches.
The kernel compared with neighboring concepts
Confusion between the kernel and the complete operating system is common. The following comparison separates the layers.
| Concept | What it includes | Example |
|---|---|---|
| Linux kernel | Hardware management and system calls only | vmlinuz image in /boot |
| GNU user space | Shell, core utilities, compiler, C library | Bash, coreutils, glibc |
| Linux distribution | Kernel, user space, packages, installer, defaults | Debian, Ubuntu, Fedora, Arch Linux |
| Microkernel design | Minimal kernel, services in user space | MINIX, seL4 |
Containers illustrate the distinction well: every container on a host shares the host kernel, isolated through namespaces and control groups, while each container brings its own user space from any distribution.
Common mistakes and misconceptions
- Treating a kernel panic as an application crash: a panic halts the whole system and usually points to a driver, hardware fault or memory corruption.
- Upgrading kernels without rebooting: the new kernel is installed but inactive until restart, unless live patching is used for specific fixes.
- Loading untrusted modules: modules run with full privileges, and with Secure Boot they must be signed.
- Assuming more swap or tuning always helps: blind
sysctlchanges copied from the internet often reduce performance. - Removing old kernels too early: keeping one previous kernel provides a fallback if a new version fails to boot.
The idea in brief
The Linux kernel is the manager that sits between the hardware and every program. When a web browser wants to show a picture or save a file, it asks the kernel, and the kernel talks to the screen, memory and disk.
Think of a busy restaurant kitchen. Diners never walk in to use the stoves themselves; they give orders to the staff, and the kitchen manager decides who cooks what, when and with which equipment. The kernel plays that role for a computer, keeping programs from getting in each other’s way.
A practical scenario
A system administrator runs a fleet of Ubuntu servers hosting a database. After a security advisory for a privilege-escalation flaw in the networking subsystem, the administrator checks the running version with uname -r and finds that it predates the fixed distribution kernel package.
The fix is installed through the package manager, and the servers are rebooted one at a time while the database replicas keep serving traffic. On one machine the new kernel fails to load a third-party storage driver, so the administrator selects the previous kernel in the boot menu, rebuilds the module for the new version and reboots again. The fleet is patched within one maintenance window, with no service outage.