What the Kernel Actually Does and Why It Is the Primary Attack Surface

The Linux kernel sits between your hardware and every application running on the server. It manages CPU scheduling, memory allocation, filesystem operations, the network stack, and the security boundaries between processes. When a PHP application calls fopen() or when Nginx accepts a connection, both go through the kernel. Because of this privileged position, the kernel is the primary security boundary on any Linux server. A vulnerability in the kernel can allow an unprivileged process to escape its sandbox, gain root access, read memory it should not access, or compromise the host entirely.

Ubuntu Long Term Support releases ship with a kernel version current at the time of release. Ubuntu 22.04 launched with kernel 5.15. As the supported period progresses, newer kernel versions are delivered through Hardware Enablement (HWE) updates, which bring updated kernels with security fixes and hardware support. Ubuntu 24.04 follows the same pattern. Staying on the initial kernel version without updating introduces known risks because security vulnerabilities discovered after your server was deployed are not patched unless you apply the updates.

The consequences of running an unpatched kernel are not theoretical. The Dirty COW vulnerability (CVE-2016-5195) allowed any unprivileged user on a Linux system to gain root access through a race condition in the kernel's memory management code. It was introduced in kernel 2.6.22 in 2007 and remained undiscovered until 2016. Any server running an unpatched kernel during those nine years was vulnerable to privilege escalation by any user, including www-data, the account that serves web applications. The patch existed for years before the vulnerability was publicly disclosed. Servers that were not updated were exposed during the window between public disclosure and the rush to patch.

More recent examples include the Sequoia vulnerability (CVE-2024-1086), a Linux kernel privilege escalation in the netfilter subsystem that allows container escape. This affects servers running kernel versions prior to 6.8. If a container workload is compromised, an attacker can escape to the host with root privileges through this vulnerability. Container isolation that relies on the kernel for security is negated when the host kernel is vulnerable.

The Three Categories of Ubuntu Kernel Updates

Ubuntu kernel updates fall into three distinct categories with different risk profiles and apply timings.

Security updates fix known vulnerabilities that have been assessed as actively exploited or likely to be exploited. Ubuntu Security Notices (USN) document each kernel security update with a CVE number, severity rating, and description of what the vulnerability allows. These should be applied within days of release, not weeks. The window between a CVE becoming public and a patch being available is when servers that have not updated are most exposed, because proof-of-concept exploit code appears quickly after disclosure. USN-6857-1 documented a kernel privilege escalation in the nf_tables subsystem that allowed local users to gain root access. Any server running an affected kernel version that had not applied the update was exploitable by any user with shell access.

Bug fix updates address non-security kernel issues: stability regressions, hardware compatibility improvements, and fixes for problems that cause kernel panics or hangs. These are lower priority than security updates but should be applied during regular maintenance windows. A kernel bug that causes OOM killer to terminate your database process under memory pressure is not a security issue but is a reliability problem that bug fix updates address.

HWE kernel updates are where Ubuntu LTS receives newer kernel versions during the support lifecycle. The initial LTS kernel is fixed at release, but HWE pushes newer kernels to provide updated hardware support and security fixes. Ubuntu 22.04 started on 5.15 and moved to 6.5 through HWE. The practical difference is that HWE kernels receive security fixes and hardware support sooner than the base kernel. Running the base kernel on an LTS release means you receive fewer updates than systems running HWE kernels.

Checking What Kernel You Are Running and What Is Available

Before applying any update, know what you are running and what you would be applying. The uname command shows the current kernel version.

uname -r

# Output: 5.15.0-91-generic

The version components break down as follows: 5 is the major version, 15 is the minor version, 0 is the revision, 91 is the ABI counter, and generic is the kernel flavour. The generic flavour is the standard server kernel. The lowlatency flavour is used for workloads requiring lower interrupt latency, such as audio production or industrial control systems, and is not typically used for web servers.

List all installed kernel versions on the system.

dpkg --list | grep linux-image

apt list --installed | grep linux-image

Ubuntu allows multiple kernel versions to coexist. When you install a new kernel package, the old one remains installed. The GRUB bootloader presents a menu at boot where you can select which kernel to run. If a new kernel breaks something, you can reboot and select the previous kernel from the GRUB menu. This is the safety mechanism that makes kernel updates recoverable. Removing old kernels after confirming a new kernel is stable frees disk space and removes the temptation to boot into an outdated kernel.

Check what kernel versions are available in the repository before installing.

apt-cache policy linux-image-generic

apt-cache search linux-image | grep "^linux-image"

On Ubuntu 22.04, the HWE kernel is linux-image-generic-hwe-22.04. On Ubuntu 24.04, the base kernel receives regular updates without needing HWE. Verify which is installed by running uname -r and comparing the version number against what apt-cache shows as available.

How to Apply Kernel Updates Without Breaking a Production Server

Kernel updates require a reboot to take effect. That is the fundamental challenge: you cannot update the kernel without restarting the server. For a production web server, this means planned maintenance downtime. The process to apply safely is: update the package cache, install the new kernel package, verify the installation, test if possible, then reboot during a maintenance window.

sudo apt update

sudo apt upgrade linux-image-generic

On Ubuntu 22.04 with HWE enabled, the equivalent command installs both the image and headers.

sudo apt install --install-recommends linux-image-generic-hwe-22.04 linux-headers-generic-hwe-22.04

sudo update-grub

sudo reboot

The update-grub command ensures the bootloader configuration includes the new kernel as the default boot option. If GRUB is not updated, the server may boot into the old kernel after reboot. Verify the bootloader configuration before rebooting.

grep -c "submenu\|menuentry" /boot/grub/grub.cfg

# If this returns 0, GRUB is not generating a proper menu

# Check /etc/default/grub and run sudo update-grub

After running update-grub, confirm the new kernel is listed as the default boot option.

grep "menuentry" /boot/grub/grub.cfg | head -5

# The first menuentry in the file is the default boot entry

If the server is inaccessible after reboot, use the hosting provider's console access to boot into the previous kernel. Most providers allow selecting a specific kernel from the GRUB menu through their console. This is why keeping the previous kernel installed and testing on staging before applying to production matters.

After reboot, verify the server is running the new kernel.

uname -r

# Should show the new version, e.g., 6.5.0-45-generic

Check system logs for any kernel-related errors that appeared during boot.

journalctl --list-boots | head -10

journalctl -b -1 -k | grep -i error

The -b -1 flag shows the previous boot's kernel log, which lets you compare the boot messages between the old and new kernel. For additional security hardening steps beyond kernel updates, it is worth reviewing your server's overall security posture, including SSH configuration, firewall rules, and access controls. A secure SSH setup on Ubuntu forms an important part of this picture.

Managing Kernel Update Risk in Production Environments

The risk of applying kernel updates to a production server is not the update itself but the uncertainty of whether the new kernel works correctly with your specific hardware and workload. The mitigation is staging: test the new kernel in an identical environment to production before applying it to production.

If you run on cloud infrastructure with identical server images, spin up a test instance, apply the kernel update, run your application workload, and verify stability before updating the production servers. For on-premises infrastructure without a test environment, apply kernel updates to the least-critical server first, observe for 24-48 hours, then apply to the rest.

When scheduling kernel updates, consider the update's urgency. A kernel security update that patches a privilege escalation being actively exploited in the wild should be applied as an emergency deployment, not deferred to the next maintenance window. A bug fix update that improves network throughput can wait for a scheduled window. The distinction between security and bug fix updates matters for urgency.

Monitor USN (Ubuntu Security Notices) for kernel updates affecting your kernel version. Subscribe to the Ubuntu security mailing list or use a monitoring tool that tracks CVE disclosures for your kernel version. A server running kernel 5.15.0-91 on Ubuntu 22.04 needs to know when kernel updates address vulnerabilities that affect that version.

Cleaning Up Old Kernels After a Successful Update

After confirming the new kernel is stable, remove the old kernel versions to free disk space and reduce boot menu clutter. On Ubuntu, use the autoremove mechanism or manual removal.

# List all kernels except the currently running one

dpkg --list | grep linux-image

# Remove old kernels

sudo apt autoremove --purge

# Or explicitly remove specific old versions

sudo apt remove linux-image-5.15.0-91-generic

sudo apt autoremove

Never remove the currently running kernel. Verify which kernel is active before removing any package.

uname -r

# Only remove kernels that do not match this version

The /boot partition can fill up if many kernel versions accumulate. Check the /boot partition usage on systems with limited disk space before installing a new kernel. If /boot is at 90% capacity, a kernel package installation can fail. Free space in /boot before applying updates on systems with small /boot partitions.

When Not to Apply a Kernel Update

There are legitimate reasons to defer a kernel update. If the server has hardware that only works with a specific kernel version, and the new kernel breaks that hardware, applying the update causes a production outage. Knowing your server's hardware dependencies matters before the update is needed.

If the new kernel introduces regressions that affect your specific workload, you may need to delay the update until the regression is fixed in a subsequent kernel release. Ubuntu's kernel team publishes regression notices when regressions are identified in updates. Check the release notes for any kernel update before applying it to production.

Do not defer security updates for more than a few days without a documented reason. Deferring a kernel security update by weeks because it is inconvenient is not a risk-managed decision. It is a risk-ignored decision that will eventually result in exploitation.

Monitoring Kernel Version Across Multiple Servers

Managing kernel updates across multiple servers requires visibility into which kernel version each server is running. A configuration management tool or inventory system that tracks kernel versions across all servers surfaces which ones are behind and need updating.

Collect kernel version data across all servers and compare against the latest available kernel for your Ubuntu version. A simple script across your fleet identifies which servers are running outdated kernels.

# Run across all servers via your CMDB or configuration tool

uname -r

# Compare against: apt-cache policy linux-image-generic

Automate this collection and alert on servers that are more than one minor version behind the latest available kernel. The gap between your kernel and the latest available kernel represents the exposure window for vulnerabilities that have been fixed in newer versions.

Ubuntu Kernel Updates and Broader Server Maintenance

Kernel updates do not exist in isolation. They are part of a broader server maintenance routine that includes applying all system updates, reviewing access controls, monitoring disk space, and testing backups. A server that receives regular kernel updates but runs outdated packages, misconfigured firewall rules, or unmonitored services still carries significant security risk.

Building a maintenance schedule that includes kernel updates alongside other routine server health checks helps keep the overall system secure. Many organisations use a monthly or quarterly maintenance window specifically for these tasks. Documenting which servers have been updated, when, and to what kernel version creates an auditable record that helps during security reviews or incident investigations.

What Matters Most With Ubuntu Kernel Updates

Ubuntu kernel updates matter because the kernel is the most privileged layer on your server. Keeping it patched against known vulnerabilities reduces the most critical attack surface. The process is straightforward: check what you are running, test the update in a staging environment, apply during a maintenance window, verify the new kernel after reboot, and clean up old versions once confirmed stable.

The harder part is building the discipline to treat kernel updates as routine maintenance rather than exceptional events. Servers that fall behind on kernel updates accumulate exposure over time. A server running a kernel that is multiple versions out of date is a significant security liability, particularly when the vulnerabilities in those older versions have public proof-of-concept exploit code available.

If you are managing servers and unsure whether your current kernel update process is adequate, reviewing the Ubuntu Security Notices for your kernel version and comparing against what is currently installed gives you a clear picture of your exposure. A practical review of your server maintenance routine can help identify gaps before they become problems.