Linux Kernel CVEs Don't Care About Your Distro's Release Schedule — Here's What Actually Happens

TL;DR: The thing that caught me off guard the first time I seriously tracked a kernel CVE was realizing I had no idea what "patched" actually meant. I'd see a CVE entry marked as resolved, open a terminal on my Ubuntu 22. 📖 Reading time: ~36 min What's in this article The Gap Between 'Kernel Patched' and 'Your Server Is Safe' How Distros Actually Handle Upstream Kernel Vulnerabilities Reading a Real Kernel CVE: CVE-2023-3269 (StackRot) as a Case Study Commands You Actually Need to Audit Your Exposure Live Patching: When It Helps and When It's a False Sense of Security Distro-by-Distro Reality Check: Patch Velocity vs. Stability Tradeoff What RHEL's 'Extended Kernel Stable' Model Actually Means for You Setting Up Automated Alerts So You're Not Reading NVD Manually The Gap Between 'Kernel Patched' and 'Your Server Is Safe' The thing that caught me off guard the first time I seriously tracked a kernel CVE was realizing I had no idea what "patched" actually meant. I'd see a CVE entry marked as resolved, open a terminal on my Ubuntu 22.04 box, run uname -r, and still be running the vulnerable kernel — sometimes 3 to 5 weeks after Linus's tree had the fix merged. That's not a hypothetical. That was my Tuesday morning. The pipeline from Linus's tree to your server is longer than most people draw it out. The fix lands in upstream, then gets backported to the stable kernel branch (Greg KH's territory), then a distro maintainer has to cherry-pick and test it against their patched tree, then it goes through QA, then it gets pushed to the package repo, and only then does apt update && apt upgrade actually fetch it. Every one of those hand-offs introduces delay. Ubuntu 22.04 ships with a custom HWE or GA kernel that isn't just upstream 5.15 — it's a fork with thousands of additional patches on top. The maintainers have to verify the CVE fix doesn't break their delta before shipping. That's real work, and it takes real time. CVE-2022-0847 — Dirty Pipe — is the clearest illustration I've seen of how unequal that delay is across distros. The vulnerability was disclosed February 20, 2022. Here's how the response actually played out: Arch Linux: Kernel 5.16.11 with the fix hit their repos within roughly 48 hours of disclosure. Arch tracks upstream closely, so the turnaround was fast. Ubuntu 22.04 (then in beta) and 20.04: Canonical pushed patched kernels within about a week — faster than usual because this one got press coverage. Debian Stable (Bullseye): Debian's stable kernel (5.10 LTS) needed a backported patch, and the DSA advisory came out roughly 5–6 days later, but deployment lag on self-managed systems stretched further. RHEL 8/CentOS Stream: Red Hat's advisory (RHSA-2022:0622) dropped March 10 — nearly 3 weeks after public disclosure. Their kernel is a heavily modified 4.18-based tree, and backporting requires thorough validation. Three weeks is a long time to have a local privilege escalation on a multi-tenant system. And Dirty Pipe was noisy — high-profile, actively discussed. CVE-2023-0386, the OverlayFS privilege escalation, got less press. It's a CVSS 7.8 that lets an unprivileged user mount overlayfs and escalate to root via a FUSE filesystem. The upstream fix landed in early 2023. Ubuntu 22.04 LTS users with the default GA kernel (5.15) waited weeks for the patched package. I was checking my Ubuntu 22.04 nodes with apt-cache policy linux-image-$(uname -r) and not seeing the patched version in the candidate slot for longer than I'd like to admit. # Check if the running kernel has a pending security update apt-cache policy linux-image-$(uname -r) # Also check what's available across all kernel meta-packages apt list --upgradable 2>/dev/null | grep linux-image # On RHEL/CentOS, check the advisory directly dnf updateinfo list security --cve CVE-2023-0386 # If the output is empty, the fix isn't in your repos yet — you're exposed Enter fullscreen mode Exit fullscreen mode The NVD problem is separate and genuinely frustrating. You pull up the CVE, see a 7.8 CVSS score with "local privilege escalation" in the description, and what you need to know is: does my running kernel contain this fix? NVD doesn't answer that. It gives you CPE strings and version ranges that reference upstream kernel versions, not distro package versions. Your Ubuntu kernel might be 5.15.0-78-generic, but the CVE references kernel , and canonical-livepatch enable. Beyond 5 machines it's part of the Ubuntu Pro subscription (~$25/machine/year for infrastructure tier). RHEL's kpatch is included in any active RHEL subscription, but that subscription starts at roughly $350/year per system for the standard tier — there's no free individual tier. SUSE's kGraft is bundled with SLES subscriptions similarly. If you're running CentOS Stream or AlmaLinux, you're looking at third-party options like KernelCare (paid) or TuxCare, since there's no native live patching infrastructure included. The mental model I actually use: live patching buys you a maintenance window extension, not permanent deferral. Budget for a kernel reboot every 60–90 days regardless. Some CVEs won't be live-patchable, some patches have bugs themselves (I've seen a kpatch cause a subtle networking regression on RHEL 8.6 that only showed under load), and eventually your live patch stack diverges far enough from the base kernel that the vendor stops issuing new ones for that kernel version anyway. On Ubuntu, Livepatch coverage for a given kernel version has a defined window tied to the kernel's support lifecycle — when the kernel ages out, live patches stop coming and you're forced to upgrade anyway. Treating live patching as a hard dependency in your uptime SLA is asking for a bad day. Distro-by-Distro Reality Check: Patch Velocity vs. Stability Tradeoff The version number on your kernel is almost meaningless without understanding how your distro backports. I've watched teams panic about a CVE, check their kernel version, see something that "looks old," and spin up emergency migration plans — when the fix was actually backported months ago. The opposite also happens: people see a high version number and assume they're safe. Neither instinct is reliable. Arch Linux: Bleeding Edge Is a Double-Edged Thing Arch ships kernel 6.x.latest typically within 2–4 days of an upstream release. For a desktop where you want hardware support for a new GPU or a WiFi chipset, this is fantastic. For anything production-facing, you're essentially running integration testing for the kernel community. The thing that caught me off guard the first time I ran Arch on a "light production" box was a 6.x point release that introduced a regression in ext4 writeback behavior. Upstream fixed it three releases later. Rolling release means you also get the regression automatically. The mitigation if you're going to run Arch in any semi-serious context: use a staging lane. Run the update on a non-critical box first, wait 48 hours, then roll forward. Alternatively, pin to a specific kernel package with: # In /etc/pacman.conf, add to IgnorePkg: IgnorePkg = linux linux-headers # Manually install a specific version from the Arch archive # https://archive.archlinux.org/packages/l/linux/ pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.8.9.arch1-1-x86_64.pkg.tar.zst Enter fullscreen mode Exit fullscreen mode This buys you time without fully opting out of updates. The real tradeoff: you get CVE fixes fast (often 1–3 days after upstream patch), but you also get every new bug that comes with the fix. Ubuntu 22.04 LTS and RHEL 9: The Backport Game Ubuntu 22.04 ships 5.15 as its default kernel, with the HWE (Hardware Enablement) track bumping you to 6.5 if you opt in. But here's the thing — whether you're on 5.15 or 6.5, Canonical is only backporting security fixes, not upstream performance improvements or non-security bug fixes. You're predictably 2 major versions behind upstream on features, which is the right call for a server OS. Where this bites you is hardware: if you're running something like a 13th-gen Intel box or an AMD Zen 4 system, 5.15 may have subpar driver support. The fix is the HWE kernel, but then your "stable LTS" is suddenly tracking a newer base with its own surprises. RHEL 9's situation is more extreme. The base is 5.14, which looks ancient. But Red Hat's backport team has pulled in fixes from 5.15, 6.0, 6.1, and beyond into that 5.14 tree. The version number is genuinely misleading. I've seen engineers dismiss RHEL 9 based on the kernel version string and that's a mistake. Check the actual patch changelog with rpm -q --changelog kernel | head -100 and you'll see backports tagged with the upstream commit they came from. The cost of this model: some upstream fixes don't get backported because they're too invasive to cherry-pick safely, and you'll occasionally hit a bug that upstream fixed in 5.16 but RHEL hasn't pulled yet. Debian Stable and Fedora: Two Honest Options Debian Bookworm runs kernel 6.1 with conservative backporting. The Debian security team is genuinely small — a handful of people handling kernel CVEs for the stable branch. But they're consistent. Critical CVEs typically land within 7–14 days. The tradeoff is that "conservative" means they sometimes wait to understand the full blast radius of a patch before shipping it, which is actually the correct call for a distro running on infrastructure you don't touch often. Fedora is the most interesting option for security researchers and sysadmins who want to understand what RHEL will look like 2 years from now. It tracks current stable kernel closely — usually within a few weeks of upstream release. Because Fedora sees regressions and CVE patches before they hit RHEL, running a Fedora CI node or staging environment is a legitimate early-warning system. I've caught behavior changes on Fedora that flagged an issue we then had to prepare for when RHEL eventually picked up the same patch set. The Comparison That Actually Matters | Distro | Base Kernel | Patch Model | Avg Days to Critical CVE Fix | Live Patch Option | |---------------------|-------------|--------------------------|-------------------------------|---------------------------| | Arch Linux | 6.x latest | Full upstream rolling | 1–3 days | None (manual kernel pin) | | Ubuntu 22.04 LTS | 5.15 / 6.5* | Security backports only | 7–14 days | Canonical Livepatch (free tier: 3 machines) | | RHEL 9 | 5.14 + huge backport set | Security + selected backports | 7–21 days | RHEL Live Kernel Patch (subscription required) | | Debian Stable (Bookworm) | 6.1 | Conservative backports | 7–14 days | None in stable repos | | Fedora (current) | ~6.x stable | Near-upstream tracking | 3–7 days | None officially | * Ubuntu HWE kernel on 22.04 Enter fullscreen mode Exit fullscreen mode The "avg days to critical CVE fix" numbers above are based on observed patch velocity from public tracker data like the Ubuntu Security Notices and Red Hat Errata feeds — not marketing claims. RHEL's wider window exists partly because their QA process is heavier. That's not a dig; it's the right call when you're responsible for kernel updates on someone's hospital billing system. For your personal dev server, Arch's 1–3 day window is a feature. For a fleet of 200 production nodes, Debian's conservative approach means fewer "the patch broke something" incidents at 3am. What RHEL's 'Extended Kernel Stable' Model Actually Means for You The most disorienting thing about running RHEL 9 for the first time after years of upstream Linux is seeing 5.14.0-362.el9 and instinctively panicking. Kernel 5.14 went end-of-life upstream in January 2022. If you hit a CVE scanner against that machine, it will light up like a Christmas tree — and most of those alerts will be completely wrong. Red Hat's model is not "ship upstream 5.14 and hope for the best." They pick a kernel version, freeze the ABI, and then backport security fixes and driver improvements from later kernels into that frozen base. By the time you're running 5.14.0-362.el9, that kernel has absorbed thousands of individual patches from kernels 5.15, 5.16, 6.0, 6.1, and beyond. The version number is essentially a stable ABI identifier, not a feature-completeness snapshot. Red Hat calls this their Extended Kernel Stable (EKS) model, and the practical effect is that your "old" kernel is dramatically more current than the version string implies. You can actually verify this directly instead of taking it on faith. Pull the changelog: # First 100 entries will show you recent CVE backports and fixes rpm -q --changelog kernel-core | head -100 # Cross-reference a specific CVE rpm -q --changelog kernel-core | grep -i "CVE-2023-4623" # Check what advisories Red Hat has shipped for your running kernel dnf updateinfo list security kernel Enter fullscreen mode Exit fullscreen mode That changelog output is dense — you'll see entries like - [net] fix use-after-free in nf_tables (CVE-2023-4623) with the RHSA advisory number attached. That fix was backported from a much newer upstream commit. The version string told you nothing useful; the changelog tells you everything. This is also why Red Hat maintains the Customer Portal advisory database — cross-referencing a CVE ID against that database, not against the kernel version, is the only accurate way to assess your exposure. The CVE scanner false-positive problem is genuinely painful in practice. Tools like Trivy, Grype, or older versions of OpenSCAP that key off the kernel version string will flag RHEL 9 machines as vulnerable to issues that Red Hat patched six months ago via backport. I've had to walk infosec teams through this more than once. The correct fix is to either configure your scanner to use Red Hat's OVAL data, or to cross-check findings against dnf updateinfo info CVE-XXXX-XXXX before writing tickets: # Check whether Red Hat considers your system patched for a specific CVE dnf updateinfo info CVE-2023-4623 # If output shows "No updateinfo info available" and you've applied current patches, # that CVE is already resolved in your installed kernel build Enter fullscreen mode Exit fullscreen mode The trade-off with this model is real though: you get ABI stability and long-term support, but you will occasionally find that a newer kernel feature genuinely isn't available — not because of a version mismatch but because Red Hat deliberately excluded it from their backport scope. eBPF capabilities, certain io_uring features, and newer LSM hooks have historically lagged behind what you'd get on Fedora 39 or Ubuntu 23.10 with kernel 6.5+. For most production server workloads that's a fine trade. For bleeding-edge container runtimes or observability tooling that wants the newest BPF program types, you'll hit the ceiling faster than you expect. Setting Up Automated Alerts So You're Not Reading NVD Manually Nobody has time to sit on the NVD website refreshing for kernel CVEs. I spent a weekend setting up a proper alerting pipeline after getting blindsided by a local privilege escalation vulnerability that had been public for two weeks before I noticed it. Here's the actual setup that keeps me ahead of things now. Ubuntu Security Notices and RHEL Errata Feeds Ubuntu publishes every security advisory at ubuntu.com/security/notices and they have a working RSS feed at https://ubuntu.com/security/notices/rss.xml. Subscribe to that in whatever feed reader you use. For email, they maintain ubuntu-security-announce@lists.ubuntu.com — subscribe at lists.ubuntu.com and you'll get mails the moment an advisory drops. Filter your inbox by [USN] in the subject, which is the prefix they use consistently. On the RHEL side, access.redhat.com/errata is the canonical place, and they expose an API endpoint you can filter by severity. CRITICAL and IMPORTANT are the ones that actually keep me up at night. Moderate kernel patches I queue for the next maintenance window, not an emergency rollout. unattended-upgrades for Debian/Ubuntu Auto-applying security updates is controversial but I do it on production servers for the security-only origin. The key config lives in /etc/apt/apt.conf.d/50unattended-upgrades. The defaults are surprisingly sane but you need to verify a few things: // /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; // NOT "${distro_id}:${distro_codename}-updates" unless you want all updates }; // Reboot automatically if needed (kernel updates almost always need this) Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "03:00"; // Send output via email — empty string disables it Unattended-Upgrade::Mail "you@yourdomain.com"; Unattended-Upgrade::MailReport "on-change"; // Keep a log Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; Unattended-Upgrade::Remove-New-Unused-Dependencies "true"; Enter fullscreen mode Exit fullscreen mode The gotcha that bit me: Automatic-Reboot defaults to false, which means a kernel patch gets applied but the running kernel doesn't change until someone manually reboots. You think you're protected but you're still running the vulnerable kernel. Either set the reboot time to your maintenance window, or use kpatch/livepatch if you genuinely can't reboot. dnf-automatic on Fedora and RHEL The Fedora/RHEL equivalent is dnf-automatic. Installation and enabling is one block: # Install and enable the timer dnf install -y dnf-automatic systemctl enable --now dnf-automatic.timer # Verify it's scheduled systemctl list-timers dnf-automatic.timer Enter fullscreen mode Exit fullscreen mode The config at /etc/dnf/automatic.conf has an upgrade_type key — set it to security instead of default to restrict auto-applies to security patches only. Same reboot caveat applies. On RHEL 9 specifically I've seen the timer silently fail if the system isn't registered with subscription-manager, which is obvious in retrospect but annoying to debug at 11pm. OSV and Its API for Programmatic Queries OSV at osv.dev is the one I actually query programmatically because their API is genuinely good. You can POST to https://api.osv.dev/v1/query and filter by ecosystem. For kernel CVEs: # Query for a specific CVE affecting the Linux kernel curl -s -X POST https://api.osv.dev/v1/query \ -H "Content-Type: application/json" \ -d '{ "package": { "name": "linux", "ecosystem": "Linux" } }' | jq '.vulns[] | {id: .id, summary: .summary, severity: .severity}' Enter fullscreen mode Exit fullscreen mode You can also query by CVE ID directly with https://api.osv.dev/v1/vulns/CVE-2024-XXXXX. The response includes affected version ranges, which is the piece I care about most — knowing whether my running 6.8.0-45 is in the affected window. I run this as a nightly cron job and push results into a small SQLite file that I diff against the previous day's output. Anything new gets piped to Slack. Routing Kernel CVE Alerts to Slack or PagerDuty My actual alerting script polls the Ubuntu security RSS feed and routes to Slack. It's less than 50 lines of Python and has been running for 8 months without needing changes: #!/usr/bin/env python3 # runs as a cron job every 4 hours # requires: pip install feedparser requests import feedparser import requests import json import os import hashlib from pathlib import Path FEED_URL = "https://ubuntu.com/security/notices/rss.xml" SLACK_WEBHOOK = os.environ["SLACK_WEBHOOK_URL"] SEEN_FILE = Path("/var/tmp/usn_seen.json") def load_seen(): if SEEN_FILE.exists(): return set(json.loads(SEEN_FILE.read_text())) return set() def save_seen(seen): SEEN_FILE.write_text(json.dumps(list(seen))) seen = load_seen() feed = feedparser.parse(FEED_URL) for entry in feed.entries: entry_id = hashlib.md5(entry.id.encode()).hexdigest() if entry_id in seen: continue # Only alert on kernel-related USNs if "linux" not in entry.title.lower() and "kernel" not in entry.summary.lower(): seen.add(entry_id) continue payload = { "text": f":rotating_light: *Kernel Advisory*: \n{entry.summary[:300]}" } requests.post(SLACK_WEBHOOK, json=payload, timeout=5) seen.add(entry_id) save_seen(seen) Enter fullscreen mode Exit fullscreen mode For PagerDuty, swap the Slack webhook call for a PagerDuty Events API v2 POST to https://events.pagerduty.com/v2/enqueue with event_action: trigger. I only do that for CVSS 9.0+ kernel CVEs — everything below that goes to Slack, not to someone's phone at 2am. The severity triage comes from parsing the OSV API response's severity array, not the RSS description which is inconsistently formatted. When a Vulnerability Is Technically Present but Not Actually Exploitable The most common mistake I see when a new kernel CVE drops is watching people immediately spin up emergency patching windows for vulnerabilities that literally cannot fire on their systems. CVSS scores don't know your kernel config. A 9.8 score on a bug that requires CONFIG_BPF_SYSCALL combined with unprivileged access means exactly nothing if your distro doesn't expose that path. Understanding this is the difference between a 2am war room and a "patch it in the next cycle" entry in your ticket queue. The eBPF case is a perfect real example. A whole class of privilege escalation CVEs from 2021–2023 (including DirtyCred-adjacent eBPF bugs) require unprivileged BPF syscall access. Ubuntu 20.04+ ships with that locked down: # Check your current status $ sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 1 # 1 means protected, 2 means permanently locked # What a vulnerable default looks like (Debian before hardening) kernel.unprivileged_bpf_disabled = 0 # If you want to harden this manually $ echo 'kernel.unprivileged_bpf_disabled=1' >> /etc/sysctl.d/99-harden.conf $ sysctl --system Enter fullscreen mode Exit fullscreen mode The value of 2 (added in kernel 5.13) is write-once — once you set it to 2 at boot, even root can't flip it back without rebooting. That's the setting you want on production servers where eBPF tooling like bpftrace is run by admins, not arbitrary users. The thing that caught me off guard the first time I dug into this: Ubuntu 22.04 defaults to 1, not 2, so a privileged process can still re-enable unprivileged BPF at runtime unless you explicitly set 2 in your sysctl config. AppArmor and SELinux genuinely change the math on local privilege escalation bugs. A CVE rated "Local, Low Privileges Required, High Impact" sounds terrifying — but if the attack requires the compromised process to have an AppArmor profile that restricts ptrace, file writes to /proc/sysrq-trigger, or specific capability usage, the practical exploitability drops significantly. This doesn't mean you skip patching, but it absolutely affects your SLA. I've started keeping a simple table: CVE → requires confinement bypass? → what MAC policy covers the at-risk process? If a web app process is under a tight AppArmor profile and the kernel bug requires writing arbitrary kernel memory from an unconfined context, that's a different risk tier than the same bug targeting a bare process. Container workloads are where I want to push back against over-confidence though. Containers share the host kernel — full stop. A kernel vulnerability that achieves privilege escalation on the host is almost always a container escape vector too, because the attack surface isn't the container runtime, it's the syscall interface. The practical question isn't "does this affect my containers" but "can an attacker reach the vulnerable kernel path from inside the container namespace." Runc and containerd do drop capabilities by default (no CAP_SYS_ADMIN, no CAP_NET_ADMIN unless you explicitly add them), so a CVE requiring CAP_SYS_ADMIN is not exploitable from a default container without privilege escalation first. Check your actual container capabilities: # What capabilities a default docker container has $ docker run --rm alpine cat /proc/1/status | grep CapEff CapEff: 00000000a80425fb # Decode it $ capsh --decode=00000000a80425fb # You'll see cap_chown, cap_net_bind_service, etc. — but NOT cap_sys_admin Enter fullscreen mode Exit fullscreen mode Reading the NVD CVSS vector string correctly is a skill worth building. Take this vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The fields that matter most for triage are AV:L (Attack Vector Local — requires local access, not network exploitable), PR:L (Privileges Required Low — needs a regular user account, not just anonymous), and S:U (Scope Unchanged — the blast radius doesn't cross privilege boundaries automatically). Compare that to AV:L/PR:N/UI:N/S:C — that last one is "no privileges needed, scope changes," which means a local unprivileged user can escape the current security context. That's your "drop everything" CVE. PR:N combined with S:C on a kernel bug is what you actually cancel the deployment window for. Everything else gets prioritized against your actual attack surface. Building a Sane Kernel Patch Policy for a Real Team The thing that breaks most teams isn't the kernel CVE itself — it's the conversation that happens after it lands: "Did we patch that already? Which hosts? Is staging on the same kernel as prod?" You need a written policy that removes all of those questions before they get asked at 11pm. Here's the actual tiered response policy I use, mapped directly to CVSS scores: CVSS 9.0+: 48-hour patch window with an emergency change request. No exceptions. These are your privilege escalation and remote code execution bugs — Dirty Pipe (CVE-2022-0847, CVSS 7.8) would have been a 2-week candidate, but something like CVE-2016-5195 (Dirty COW, CVSS 7.8) retroactively taught everyone to treat anything touching memory maps as critical. When a 9.0+ drops, you open the change ticket first, then start building the patch test. CVSS 7.0–8.9: 2-week window, standard change management, goes through your normal staging → canary → prod pipeline. Below 7.0: Next monthly maintenance window. These still get tracked — just not rushed. Staging that doesn't mirror your production kernel version exactly is theater. I've been burned by this: staging was on 5.15.0-91-generic, prod was on 5.15.0-88-generic, and a patch that applied cleanly in staging exposed a driver regression in prod because of a subtle difference in the ext4 writeback behavior between those two point releases. The fix is boring but non-negotiable — your staging hosts should be provisioned from the same AMI or base image snapshot as production, and kernel updates should hit staging first with a minimum 24-hour soak before you touch prod. Knowing what kernel every host is running should take one command. This Ansible ad-hoc gets you there immediately: # Run against your full inventory, pipe through sort to spot outliers ansible all -m command -a 'uname -r' -i inventory.ini | grep -v "SUCCESS\|CHANGED" | sort # Expected output shape: # web-01 | SUCCESS | rc=0 >> # 5.15.0-91-generic # web-02 | SUCCESS | rc=0 >> # 5.15.0-88-generic > # 6.5.0-21-generic <-- this is on a different major version entirely, why? Enter fullscreen mode Exit fullscreen mode That sort at the end is the key — it groups identical kernel versions together so outliers pop out visually. I run this as a weekly cron that dumps output to a Slack channel. Any host not on the expected version gets flagged for investigation before the next patch cycle. You can also store the output as JSON with -m setup -a 'filter=ansible_kernel' if you want to feed it into a dashboard. The doc that actually saves time is a running CVE log — not a spreadsheet, just a markdown file in your team's internal wiki. Every CVE gets one row: the CVE ID, CVSS score, which kernel versions are affected, the date you patched, the kernel version you patched to, and which host groups were affected. The reason this pays off: Qualys, Tenable, and similar scanners will re-flag CVEs that are already patched if your kernel version string doesn't match their expected fix version. Without the log, someone spends 45 minutes re-researching a CVE you handled three months ago. With it, you paste the row into the ticket and close it in 5 minutes. Keep it versioned in git so you have a diff history — that audit trail is exactly what compliance teams want when they ask "show me your patch evidence for Q3." Quick Note on Tooling for Smaller Teams The honest reality for small teams: you're not running a vulnerability management program. You're running a company (or a service) that happens to have servers. Two engineers cannot realistically triage kernel CVEs, maintain a patch window schedule, test against staging, and keep shipping features. Something has to give, and it should be the elaborate process, not the patching itself. My actual recommendation is boring and I stand by it — Ubuntu 22.04 LTS or 24.04 LTS with unattended-upgrades properly configured, or RHEL 8/9 with dnf-automatic. Not because these are technically superior, but because the security backporting these distributions do means you get kernel vulnerability fixes without riding the upstream kernel version train. Canonical and Red Hat backport patches into stable kernel ABIs, so your 5.15.0-131 might contain a fix that landed in 6.8 upstream — you'd never know from the version number alone, but the CVE database will show it as resolved. # Ubuntu — check that unattended-upgrades is actually doing security patches cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -A2 "Allowed-Origins" # This line must be uncommented and present: # "${distro_id}:${distro_codename}-security"; # Then verify it's running on schedule systemctl status unattended-upgrades journalctl -u unattended-upgrades --since "7 days ago" | grep -i "upgraded\|error" Enter fullscreen mode Exit fullscreen mode The thing that catches teams off guard: enabling unattended-upgrades is not enough. You need to confirm it's actually applying security updates, not just installed and silently failing. I've inherited infrastructure where the service was running but the mail config was broken, so failure notifications were going nowhere and the packages hadn't updated in four months. Run that journalctl check above once a month minimum. For CVE awareness without a dedicated security engineer, I'd pick one of two lightweight approaches: subscribe to Ubuntu's USN mailing list filtered for kernel notices (USN entries that start with "kernel"), or set up a free OSV.dev query against your installed kernel package. You don't need a full SBOM pipeline — you need to know when a CVSS 9+ kernel CVE drops so you can decide whether to push a manual patch cycle instead of waiting for the weekly automation window. If you're managing more than a handful of servers and want tooling that gives you visibility across the whole stack — not just kernel patches but config drift, dependency exposure, and update status — there's a broader breakdown worth reading in the Essential SaaS Tools for Small Business in 2026 guide. The kernel is one layer; for a two-person ops team the real use is in consolidating how you track all of it, not building bespoke processes for each concern. Disclaimer: This article is for informational purposes only. The views and opinions expressed are those of the author(s) and do not necessarily reflect the official policy or position of Sonic Rocket or its affiliates. Always consult with a certified professional before making any financial or technical decisions based on this content. Originally published on techdigestor.com. Follow for more developer-focused tooling reviews and productivity guides.