A kernel vulnerability makes the news, and the question is simple: am I patched? The obvious check, uname -r, is often misleading, because most distributions fix security bugs without changing the kernel’s upstream version number. This guide shows how to get a real answer.

It is timely. In September 2026 alone, four kernel root exploits went public and CISA flagged three kernel CVEs as actively exploited.

Why uname -r is not enough

Upstream, a fix lands in the mainline kernel and is then backported to maintained stable branches, producing versions like 6.12.109 or 6.6.157. An advisory will say something like “fixed in 6.12.109.”

Distributions then take one of two approaches:

• Ship upstream stable releases with few changes (Arch, Fedora to a degree). Here the version number is meaningful, and comparing it to the advisory works.
• Freeze a version and backport fixes into it (Debian, Ubuntu, RHEL, SUSE). An Ubuntu 26.04 kernel stays on the same base version for its whole life, and security fixes arrive as new package revisions. The upstream version in uname -r never reaches “6.12.109,” even when the fix is in.

So on most enterprise and LTS systems, you check the package, not the kernel version.

Step 1: find the fixed package version

Every major distribution runs a security tracker that maps CVE IDs to fixed package versions per release:

Distro	Where to look
Debian	security-tracker.debian.org/tracker/CVE-YYYY-NNNNN
Ubuntu	ubuntu.com/security/CVE-YYYY-NNNNN
Fedora	Bodhi updates and dnf updateinfo
RHEL, Alma, Rocky	access.redhat.com/security/cve/CVE-YYYY-NNNNN
Arch	security.archlinux.org
openSUSE / SLES	suse.com/security/cve/CVE-YYYY-NNNNN.html

Each tells you, per release, whether the package is vulnerable, fixed (and in which version), or not affected (for example, because the vulnerable code was never in that release’s kernel).

Step 2: compare with what is installed

Debian and Ubuntu

# Installed kernel packages and their versions
dpkg -l 'linux-image-*' | grep ^ii

# Search the changelog of the running kernel's package for the CVE
apt changelog "linux-image-$(uname -r)" | grep -i CVE-2026-81000

On Debian, debsecan lists every known unfixed CVE on the system:

sudo apt install debsecan
debsecan --suite "$(lsb_release -cs)" --only-fixed | grep linux

On Ubuntu systems attached to Ubuntu Pro (free for personal use), there is a purpose-built command:

pro fix CVE-2026-81000

It reports whether the CVE affects you and offers to install the fix.

Fedora, RHEL, Alma, and Rocky

dnf knows which advisory fixes which CVE:

# Is there an advisory for this CVE, and do I still need it?
dnf updateinfo list --cve CVE-2026-81000

# Install only that fix
sudo dnf upgrade --cve CVE-2026-81000

# Or search the installed kernel changelog
rpm -q --changelog kernel | grep -i CVE-2026-81000

An empty result from updateinfo list with the CVE means no pending update fixes it: either you already have it or no fix is published yet. The tracker tells you which.

Arch

Arch ships close to upstream stable, so the version comparison works:

pacman -Q linux
uname -r

Compare with the fixed stable version in the advisory, or check security.archlinux.org. If you run linux-lts, compare against the LTS branch’s fixed version.

Step 3: make sure you are running the fixed kernel

This is the step most people miss. Installing a kernel package puts the new kernel on disk. The old one keeps running until you reboot.

# What is running
uname -r

# What is installed (Debian/Ubuntu)
ls /boot/vmlinuz-*

# Debian / Ubuntu flag a pending reboot
cat /var/run/reboot-required 2>/dev/null

# Fedora / RHEL
sudo dnf needs-restarting -r

If the running version is older than the newest installed kernel, reboot. If you cannot reboot soon, kernel live patching can apply some fixes to the running kernel, and our guide to updating Linux safely covers scheduling reboots on servers.

Step 4: decide whether it matters to you

The Linux kernel became its own CVE Numbering Authority in 2024 and assigns CVEs to a very large number of fixes, often thousands a year. Many are in drivers you do not have loaded, or require configurations you do not use. Triage helps you prioritise, though the right default is still to install kernel updates promptly.

Is the subsystem in use? Many bugs live in loadable modules:

lsmod | grep -E '^(sctp|pppoe|tun|ah6|tls)\b'

If the module is not loaded and nothing will load it, the bug is not reachable today. Blocking it from loading can be a stopgap until you reboot, as our kernel modules guide describes.

What are the prerequisites? Advisories usually say whether an attacker needs local access, specific capabilities, or unprivileged user namespaces. A local-only bug matters much more on a shared server than on a single-user laptop.

Is it being exploited? CISA’s Known Exploited Vulnerabilities catalog lists CVEs with confirmed attacks. Anything on it moves to the top of the list.

CPU vulnerabilities are different

Hardware side-channel issues like Spectre variants are mitigated by a combination of kernel code and CPU microcode, and the kernel reports the current status directly:

grep . /sys/devices/system/cpu/vulnerabilities/*

Each line says “Not affected,” “Mitigation: …,” or “Vulnerable.” Microcode updates arrive through your distro’s intel-microcode or amd-ucode packages or through firmware; our firmware and microcode guide covers both.

Staying ahead of it

Checking CVEs one at a time does not scale. The sustainable approach is:

• Enable automatic security updates, such as unattended-upgrades on Debian and Ubuntu or dnf-automatic on Fedora and RHEL
• Schedule regular reboots so installed kernels actually run
• Subscribe to your distribution’s security announcement list

Our guide to keeping Linux updated walks through setting each of those up.

Frequently Asked Questions

Can I tell if a CVE is fixed from uname -r?

Only on distributions that ship upstream stable kernels with little modification, such as Arch. Debian, Ubuntu, Fedora and RHEL backport security fixes into older version numbers, so a kernel that looks old can contain the fix. Check the distribution security tracker or package changelog instead.

How do I check a CVE on Ubuntu?

Look the CVE up on the Ubuntu CVE tracker, which lists the fixed package version for each release, then compare it with your installed linux-image package from dpkg -l. On systems attached to Ubuntu Pro, the pro fix command followed by the CVE ID checks and applies the fix directly.

How do I check a CVE on Fedora or RHEL?

Run dnf updateinfo list —cve followed by the CVE ID to see which advisory fixes it and whether your system still needs it. You can also search the kernel package changelog with rpm -q —changelog kernel piped into grep for the CVE ID.

I installed the fixed kernel. Am I protected?

Not until you boot it. Package managers install the new kernel alongside the running one, and the old kernel stays in memory until a reboot. Compare uname -r with the newest installed kernel, or use needs-restarting -r on Fedora and RHEL or the reboot-required file on Debian and Ubuntu.

What is the Linux kernel CNA?

Since 2024 the Linux kernel project is its own CVE Numbering Authority and assigns CVE IDs to kernel fixes itself. It assigns them generously, often thousands per year, so most kernel CVEs are minor or only reachable in unusual configurations. The announcements go to the linux-cve-announce mailing list.

How do I know if a kernel CVE even affects my system?

Check whether the affected subsystem is in use. Many kernel CVEs are in drivers or protocols that live in loadable modules, so lsmod shows whether the code is loaded. Also check prerequisites in the advisory, such as needing unprivileged user namespaces or local access.