Mitigating 400+ Linux Kernel CVEs in Your Homelab

Since the Linux kernel became its own CVE Numbering Authority in 2024, it assigns CVEs to a large share of the bugs fixed in stable kernels. Many are old, obscure or low-impact. Hundreds can arrive in a short time, which looks alarming on a scanner and tells you little about what to patch first.

For a homelab this isn’t a signal to unplug everything. It’s a test of whether you can separate the few bugs that matter from the noise, and patch without constant manual work.

The Problem is Triage, Not Ticking Clocks

First, let’s get one thing straight. You are not going to patch all 400+ CVEs tomorrow. You aren’t even going to track them all manually. The sheer volume makes that impossible. The kernel’s new CVE strategy means we get more transparency, but it also means we’re drowning in low-severity alerts.

The goal is not to have zero CVEs. The goal is to mitigate unacceptable risk.

In a homelab, risk is specific to your setup. A practical way to break it down:

1. Critical Risk: Internet-Facing Services. A vulnerability in the network stack (TCP/IP, netfilter) or in a service you expose directly (like a WireGuard VPN endpoint) is your top priority. These are remotely exploitable and need to be fixed now.
2. High Risk: Container/VM Escape. On a Proxmox host, any bug in KVM, QEMU or cgroups that lets a guest affect the host is a big deal, even if you don’t run untrusted workloads: it’s a critical security boundary.
3. Medium Risk: Local Privilege Escalation (LPE). An attacker who already has low-privilege shell access can use an LPE to become root. In a typical single-user homelab, this risk is lower. If you give accounts to friends or run multi-tenant services, its priority goes way up.
4. Low/Informational Risk: Everything Else. A bug in a Bluetooth driver you don’t use? A denial-of-service that needs physical access to a USB port? Those get patched in the normal update cycle.

Your priority list might look different. The point is to have one. Write it down. This is your bible for the next step.

Worked examples from this tier list

Abstract tiers are easy to agree with and hard to apply, so here is where some 2026 kernel bugs land:

• LPE with public exploits: Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 and CVE-2026-43500), Fragnesia (CVE-2026-46300) and RefluXFS (CVE-2026-64600). Local only, but with working exploits they move up the list on any host where containers, other users or exposed services can run code.
• LPE published before any patch existed: Dirty Frag again, the awkward case: for a while the only move was a mitigation, not a version bump.

Worth reading alongside: why kernel CVE numbers are a poor signal.

Step 1: Assess with a Real Scanner

Stop running uname -r and trying to cross-reference it with a CVE list. That way lies madness. You need an automated tool that understands your distribution’s packaging and backports.

A good free choice is Trivy, an open-source scanner from Aqua Security. Its rootfs mode scans a host’s installed OS packages against your distribution’s security data, including backports.

Install it on your main Linux boxes. Here’s a one-liner to get it done:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

Now, run a scan focused only on high and critical vulnerabilities. We’re filtering out the noise from the start.

# Scan the host's OS packages for high and critical vulnerabilities.
# --exit-code 1 makes the command fail when something is found (useful in scripts).
sudo trivy rootfs --pkg-types os --scanners vuln --severity HIGH,CRITICAL --exit-code 1 /

The output lists each vulnerable package, the CVE ID, the severity and the version that contains the fix. This is your to-do list.

Expect a long list of “medium” findings. Stick to your priority list: highs and criticals first, and anything with a public exploit.

Step 2: Patch with Automated Tooling

You have your list. Now what? You could apt upgrade or dnf update manually, but who has time for that? This is a solved problem. We’re going to use the tools built into our distros.

For Debian/Ubuntu, it’s unattended-upgrades. For Fedora/RHEL, it’s dnf-automatic.

This guide uses unattended-upgrades (Debian and Ubuntu). The goal is to install only security updates automatically, so a feature update to a random package doesn’t break something at 3 AM.

Install the package first: sudo apt install unattended-upgrades.

Then, edit the configuration at /etc/apt/apt.conf.d/50unattended-upgrades. You need to make sure the right repository is enabled. For Ubuntu it looks like this; the key line is ${distro_id}:${distro_codename}-security. Debian’s file uses Origins-Pattern lines instead, with codename=${distro_codename}-security,label=Debian-Security for security updates:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        // Extended Security Maintenance; doesn't exist for standard LTR.
        // "${distro_id}ESMApps:${distro_codename}-apps-security";
        // "${distro_id}ESM:${distro_codename}-infra-security";
};

Enable the service with sudo dpkg-reconfigure -plow unattended-upgrades and select “Yes”.

Now the system installs security updates daily on its own.

Step 3: The Reboot Problem

Your system has the new kernel package installed. But it’s not running. The old, vulnerable kernel is still in memory. You have to reboot.

Live patching (Canonical Livepatch on Ubuntu, commercial services elsewhere) exists, but for a homelab a scheduled reboot is simpler.

A simple strategy: a weekly reboot in a maintenance window, for example Sunday at 4 AM. unattended-upgrades can also reboot by itself only when an update needs it (Unattended-Upgrade::Automatic-Reboot). On Proxmox hosts with running guests, reboot by hand after migrating or shutting down VMs instead of from cron.

# Add this to root's crontab with 'sudo crontab -e'
# Reboot every Sunday at 4:00 AM
0 4 * * 0 /sbin/reboot

This is the part people often forget. Patching isn’t complete until the service (in this case, the kernel) is restarted. A weekly reboot ensures your automated patches actually become effective in a timely manner.

Step 4: Verify and Repeat

After your scheduled reboot, how do you know it worked?

1. SSH back in and run uname -r to confirm you’re on the new kernel.
2. Run the Trivy scan again: sudo trivy rootfs --pkg-types os --scanners vuln --severity HIGH,CRITICAL /.

The high-severity kernel CVEs should be gone. If they are, your system is working. If not, it’s time to check the logs (/var/log/unattended-upgrades/) and figure out what went wrong.

This loop, Assess, Patch, Reboot, Verify, is the core of vulnerability management. By automating each step, you can handle hundreds of CVEs without burning out. You’ve built a system that filters the noise and addresses real risk, which is a far more valuable skill than manually patching servers in a panic.

What’s Next

Now that you have a solid kernel patching strategy, you can improve other areas of your homelab’s security and operations.

• Set Up Unattended Upgrades: Dive deeper into the configuration for automatically patching your user-space applications with our Full Guide to Unattended-Upgrades on Debian.
• Harden Your Host: Kernel patching is just one piece. Learn about firewall rules, user access control, and more in our Linux Security Hardening Guide.
• Monitor Everything: How do you know if a patch failed or a server didn’t come back up after a reboot? Set up monitoring with Prometheus and Grafana for Your Homelab.