# Linux Kernel CVE Patching: Installed Is Not Patched

- Author: Abdullah Chaudary
- Category: Infrastructure
- Published: 2026-10-20T16:37:01.471Z
- Updated: 2026-10-20T16:37:01.499Z
- Reading time: 10 min
- Tags: Linux, Kernel Security, CVE, Ansible, Patch Management, VPS

> Linux kernel CVE patching splits at the hypervisor. A VPS provider patches the host kernel, sometimes with a restart; you patch and reboot every kernel you run yourself, as CVE-2026-99999 showed.

The journal for my VPS's previous boot ends at 14:21:20 CEST on 19 October 2026. The last lines are ordinary cron and firewall entries. There is no systemd shutdown sequence, which is consistent with the VM being stopped from outside. The next boot starts at 14:36:05, on kernel 6.8.0-147-generic. Every boot since 17 January had run 6.8.0-90-generic.

Kernel 6.8.0-147 had been installed for five days. unattended-upgrades wrote it to disk at 06:50:10 on 14 October, and nothing loaded it until my provider restarted the server. Linux kernel CVE patching has two steps, install and boot, and on a VPS the host's kernel is a third thing that is not mine to patch.

**TL;DR:** On a VPS, the provider patches the host kernel, and some providers restart your server to load it; updating your own kernel does not touch the host. Every kernel you run yourself needs its own install, its own reboot and a check of the running version. On 19 October 2026 Contabo's restart loaded a kernel that had waited five days. For client dedicated servers I used IaC that checks, upgrades, does a rolling reboot, health-checks and confirms the running version, and nothing broke. CVE-2026-99999 is CVSS 9.3 from the kernel CNA and 8.8 from Red Hat, SUSE and Amazon, with no exploitation recorded by CISA as of 16 October.

My news bot, an n8n automation I built, flagged the CVE. What followed was a stressful week even though nothing broke: a critical rating, a researcher predicting public exploits within weeks, a provider restarting servers on its own timetable, and client servers that were mine to patch.

## Is CVE-2026-99999 (PwnEscape) a Risk to a VPS or a Dedicated Server?

CVE-2026-99999 is a risk to any machine whose kernel processes untrusted guest packets: a VPS host, or a server that hosts virtual machines or lets local users reach a TUN or AF\_PACKET path. A VPS customer's own kernel is not that host. The bug is a Linux kernel IPv4 checksum flaw, fixed upstream by commit 6785011f8b16.

The mechanism, as the researcher describes it: a guest supplies checksum metadata through virtio-net, and the host kernel later completes the checksum using that metadata. A bad `csum_start` makes the write land inside the already-validated IPv4 header, the fragmenter then trusts a longer header, and 32 bytes of host memory leave in the emitted packet. A GPT-5.6 Sol-driven harness did the search, with humans leading the research, according to pwn.ai.

What was shown, and where:

- **Memory leak:** against Vercel's production sandboxes (Vercel, 14 October 2026).
- **Host crash and code execution:** on researcher-owned machines: a host crash on Linux 6.12 and 7.x hosts, and code execution on a KVM fixture. pwn.ai says it makes no claim of root command execution in any vendor's production environment.

Fixed upstream versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11, plus 7.3 on mainline. I state no affected range, because the sources disagree on where it starts: the kernel CNA says 2.6.27, AWS's bulletin says 4.4.

The two severity scores differ for a reason. The kernel CNA scores 9.3 with no privileges required, since a tenant needs no host credentials. Red Hat, SUSE and Amazon score 8.8, which assumes the attacker holds low privileges inside the guest. CISA's 16 October entry records exploitation as "none", and the CVE is not in the CISA KEV catalog (version 2026.10.16). pwn.ai expects exploits for weaker configurations within weeks and for default hypervisor configurations within a month.

## Which Distributions Had a Fixed Kernel by 20 October?

Debian and Amazon Linux had fixed kernels; Ubuntu, Red Hat and SUSE did not yet. As of 19 and 20 October 2026, the trackers showed:

- **Debian:** bookworm fixed in 6.1.190-1 (DLA-4841-1), trixie fixed in 6.12.113-1 (DSA-6568-1).
- **Amazon Linux:** fixed kernels released on 1 and 12 October, before the CVE was public. Amazon's 6.1 fix is 6.1.188, lower than upstream's 6.1.190.
- **Ubuntu:** every release listed as "needed", priority Medium despite the 9.3 score.
- **Red Hat:** RHEL 6 to 10 affected, no erratum, and no mitigation that met Red Hat's criteria.
- **SUSE:** "pending", all listed products affected.

The Amazon numbers are the reason not to compare a distro kernel against the upstream list. The distro advisory is the reference.

My VPS runs Ubuntu 24.04.3 LTS. So I do not claim that 6.8.0-147 fixes this CVE; it was installed on 14 October, a day before the CVE was published, and Ubuntu still showed "needed".

## Why Does a VPS Provider Reboot Your Server for a Kernel CVE?

Because the vulnerable kernel is the provider's host kernel, and a new kernel loads only at boot. Contabo's notice of 15 October 2026 (19:33 UTC+2) said the flaw "affects the host systems underlying all VPS and VDS products" and that customers "should expect VPS or VDS to restart". Updating a guest kernel does not change the host's.

The notice said fixes would be deployed "gradually as they become available", so I had a period, not an hour. It also recommended keeping recent backups and making sure services start automatically after a reboot. The reboot arrived on 19 October, and I read the timing afterwards in my own journal.

The split of work, for a VPS:

- **The provider patches:** the host kernel and hypervisor under your server, and may restart it to load them.
- **You patch:** every kernel you run yourself, which means your guest kernel and any dedicated server.
- **You prepare:** services that start without help after someone else's restart.

Providers chose different routes. Akamai reported on 17 October (05:07 UTC) that it had completed patching its Compute hypervisors. Hetzner posted a Cloud Server item on 19 October (11:02 UTC) describing a temporary mitigation that detects the attack vector at the system level; no reboot was announced. AWS's bulletin of 15 October says EC2, Lambda and Fargate are not affected, while self-managed KVM hosts on Amazon Linux must patch and reboot. A restart is one provider's choice.

## How Do You Know the Patched Kernel Is the One Running?

Compare the running kernel with the newest installed one. `uname -r` prints what is running, `dpkg -l 'linux-image-*'` lists what is on disk, and `needrestart` reports an obsolete running kernel. A package update changes nothing in memory until the machine boots.

On my VPS the records were:

- `last -x reboot` shows 6.8.0-90-generic for every boot since January, and 6.8.0-147-generic from 19 October.
- `/var/log/dpkg.log` shows linux-image-6.8.0-147-generic (6.8.0-147.147) installed by unattended-upgrades at 06:50:10 on 14 October.
- `Automatic-Reboot` was commented out, so it sat at its default of off.

The gap was mine. The box installed a new kernel, any package report would call it patched, and it kept running the old one for five days because no reboot was scheduled. Contabo's maintenance window closed that gap before a reboot of my own did.

The fix for that failure is a check, not a promise: alert when the installed kernel differs from the running one.

Kernel CVE volume is the second reason routine updates are not a CVE response. The kernel CNA issues a CVE for any bugfix it identifies, and Tom's Hardware (1 September 2026) quotes networking maintainer Jakub Kicinski saying "We are completely overwhelmed". This fix reached Debian inside DSA-6568-1 (273 CVEs) and DLA-4841-1 (924 CVEs). A critical fix arrives buried in a batch, and the batch does not tell you which entry is the reason to reboot now. A scanner reports the batch, as covered in [what a CVE gate in CI does and does not cover](/blog/trivy-snyk-gitlab-ci-security-gate); it does not reboot the host.

## How Does Linux Kernel CVE Patching Work Across Dedicated Servers?

One host at a time: update, check that the running kernel differs from the installed one, reboot, wait for the host to answer, health-check, then move on. A dedicated server has no provider patching under it, so the install and the reboot are both yours.

I patched the dedicated servers I run for clients myself. They sit with providers including Hetzner, Leaseweb and RedSwitches. I wrote IaC that checks the kernel, upgrades, does a rolling reboot, health-checks and confirms the running version. Nothing had to be done by hand, nothing broke, and it did not take long. Patching comes back in house when you self-host, a trade-off costed in [what self-hosting really costs against a cloud bill](/blog/aws-self-hosted-migration-cost); this CVE was that trade-off in practice.

**The playbook below is not the client playbook.** It is an illustrative Ansible playbook written for this post, and I ran it against a test target. It follows the same steps. Ansible's `serial` keyword runs a play in batches, and `serial: 1` means one host per pass, so a bad kernel costs one host, not the fleet. The `reboot` module reboots, waits for the machine to go down and come back, and runs a test command, with `reboot_timeout` as the limit. The expected version is a variable per release, because distro fixed versions differ from upstream (Amazon's 6.1.188 against upstream's 6.1.190). The key tasks, condensed (the full file is longer):

```yaml
- name: Patch kernel for CVE-2026-99999
  hosts: all
  become: true
  serial: 1                 # one host per pass
  max_fail_percentage: 0    # any failed host stops the rollout
  tasks:
    - name: Upgrade kernel packages
      ansible.builtin.apt:
        name: "{{ kernel_packages[ansible_facts['distribution']] }}"
        state: latest
        only_upgrade: true
        update_cache: true

    - name: Reboot into the new kernel
      ansible.builtin.reboot:
        reboot_timeout: "{{ reboot_timeout_seconds }}"
        test_command: uname -r
      when: reboot_needed | bool   # newest kernel in /boot != uname -r

    - name: Look up the package version of the running kernel
      ansible.builtin.command: dpkg-query -W -f=${Version} linux-image-{{ kernel_after.stdout }}
      register: running_pkg
      changed_when: false

    - name: Gate - kernel must be at or above the fixed version
      ansible.builtin.assert:
        that: version_cmp.rc == 0   # dpkg --compare-versions <running> ge <fixed>
        fail_msg: "NOT PATCHED, stopping the rollout"

    - name: Health - HTTP endpoint returns 200
      ansible.builtin.uri:
        url: "{{ health_url }}"
        status_code: 200
      register: http
      retries: "{{ health_retries }}"
      until: http.status == 200
```

The fixed versions live in variables, one per release: Debian trixie `6.12.113-1` (DSA-6568-1) and bookworm `6.1.190-1` (DLA-4841-1). Ubuntu has no entry, because no fixed kernel was published, so the gate fails on Ubuntu until there is one. The full playbook adds the reboot decision, a systemd service check and a summary line.

The gate asserts that the running kernel's package is at or above the fixed version. A playbook that cannot fail is not checking anything, so the lab run covers both outcomes.

I ran it with ansible-core 2.20.5 against a disposable Debian trixie container that started on the older 6.12.107-1 kernel. With the real fixed version, the upgrade pulled 6.12.113-1 and the gate passed:

```text
"msg": "PATCHED: kcve-trixie kernel package 6.12.113-1 >= fixed 6.12.113-1 for CVE-2026-99999 (source: newest_installed)."
kcve-trixie : ok=17 changed=1 unreachable=0 failed=0 skipped=3
```

With the fixed version set one release higher, the play stopped at the gate and the health checks never ran:

```text
"msg": "NOT PATCHED, stopping the rollout: kcve-trixie (trixie) kernel
  package '6.12.113-1' (source: newest_installed, uname -r 6.8.0-147-generic)
  is not >= fixed '6.12.114-1' for CVE-2026-99999."
kcve-trixie : ok=14 changed=0 unreachable=0 failed=1 skipped=2
```

A container cannot reboot, so the lab gated on the newest installed package (`source: newest_installed`) instead of the running kernel, and the reboot task was skipped. Notice `uname -r` in that output: inside the container it reported the Docker host's kernel, 6.8.0-147-generic, because a container has no kernel of its own. On real hosts the playbook's default reads the running kernel's package, which is the check this post is about.

## What Should Come Back After a Forced Reboot?

Everything that was running should start without help. On my VPS every container carries `restart: unless-stopped`. All but two started at 14:36:13 CEST, about 8 seconds after boot. Two started about 30 seconds later, because they depend on others. No manual action was needed.

Contabo's notice gave the same advice about services starting automatically. The server runs this site, described in [how this site runs on one VPS](/blog/one-vps-nextjs-payload-cloudflare-nginx). The outage was the gap between the last journal line and the next boot: 14:21:20 to 14:36:05, about 15 minutes. How containers interact with the host kernel gets its own write-up.

## Limitations: What Does This Post Not Establish?

The figures are what I read between 19 and 20 October 2026, and CVE status changes by the day.

- **Host kernel:** from inside a VPS I cannot see which kernel Contabo's host runs, so the patch is inferred from the notice and the reboot.
- **The 147 kernel:** installed 14 October; I did not verify that it carries the fix.
- **Exploitation:** Red Hat's statement calls this a KEV active-exploit case, while the KEV catalog I checked (2026.10.16), CISA's SSVC entry and Akamai show none. Re-check on the day.
- **Live patching:** not covered. Canonical describes Livepatch as covering high and critical CVEs; whether it covers this one, which Ubuntu rates Medium, was not checked.
- **Playbook:** illustrative, not the client code. Tested in a Debian trixie container only, so the reboot task, the systemd check and the Ubuntu reboot-required path were not exercised.

If your provider rebooted a server of yours this month, how did you find out which kernel it came back on?

More in [Infrastructure field notes](/blog/category/infrastructure).

## References

- Linux kernel CNA, [CVE-2026-99999 record](https://cveawg.mitre.org/api/cve/CVE-2026-99999), published 15 October 2026, updated 19 October 2026.
- Linux kernel, [commit 6785011f8b16, "ipv4: validate checksum\_start before completing checksum"](https://github.com/torvalds/linux/commit/6785011f8b16abf40b1e9d8b2e332232b3e68822), authored 7 October 2026.
- PWNAI Research, [PwnEscape write-up](https://pwn.ai/blog/pwnescape), page created 15 October 2026, read 20 October 2026.
- Vercel, [Findings from the $1 million Vercel Sandbox challenge](https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge), 14 October 2026.
- CISA, [Known Exploited Vulnerabilities catalog](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json), version 2026.10.16.
- Ubuntu, [CVE-2026-99999](https://ubuntu.com/security/CVE-2026-99999), published 15 October 2026, read 20 October 2026.
- Debian, [security tracker entry](https://security-tracker.debian.org/tracker/CVE-2026-99999), read 20 October 2026; [DSA-6568-1](https://security-tracker.debian.org/tracker/DSA-6568-1); [DLA-4841-1](https://security-tracker.debian.org/tracker/DLA-4841-1).
- Red Hat, [CVE-2026-99999 data](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-99999.json), public 15 October 2026, read 19 October 2026.
- SUSE, [CVE-2026-99999](https://www.suse.com/security/cve/CVE-2026-99999.html), read 19 October 2026.
- Amazon Linux, [CVE-2026-99999](https://explore.alas.aws.amazon.com/CVE-2026-99999.html) and [ALAS2-2026-3962](https://alas.aws.amazon.com/AL2/ALAS2-2026-3962.html), updated 15 October 2026.
- AWS, [Security Bulletin 2026-137-AWS](https://aws.amazon.com/security/security-bulletins/2026-137-aws/), 15 October 2026.
- Contabo, [status notice](https://contabo-status.com/), 15 October 2026, 19:33 UTC+2.
- Hetzner, [status item for CVE-2026-99999](https://status.hetzner.com/en), posted 19 October 2026, 11:02 UTC.
- Akamai/Linode, [incident history](https://status.linode.com/api/v2/incidents.json), 15 to 17 October 2026.
- Tom's Hardware, [Linux kernel nears record 2,000 vulnerabilities per release](https://www.tomshardware.com/software/linux/linux-kernel-nears-2-000-cves-per-release-as-ai-bug-hunters-scour-40-million-lines-of-code-maintainers-say-they-are-completely-overwhelmed), 1 September 2026.
- Ansible, [reboot module source](https://raw.githubusercontent.com/ansible/ansible/devel/lib/ansible/modules/reboot.py) and [playbook strategies (serial)](https://raw.githubusercontent.com/ansible/ansible-documentation/devel/docs/docsite/rst/playbook_guide/playbooks_strategies.rst), read 20 October 2026.
- needrestart, [project repository](https://github.com/liske/needrestart), read 20 October 2026.
- Canonical, [Livepatch documentation](https://ubuntu.com/security/livepatch/docs), read 20 October 2026.