CVE-2026-99999 kernel check

Tools to find out whether a Linux KVM host is affected by CVE-2026-99999 and what kernel it needs.

File	Runs on	Purpose
`check_cve_2026_99999.sh`	the host being checked	Checks the running kernel, installed kernels and available fixed kernels
`scan_hosts.py`	your workstation / jump box	Runs the check on many hosts over SSH and writes a report
`hosts.example.ini`	–	Example host list

About the CVE


Introduced	Linux 2.6.27 (commit `f43798c27684`)
Fixed in	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, 7.3-rc7 and later
Code	`include/net/ip.h`, `net/ipv4/ip_output.c`, `net/bridge/netfilter/nf_conntrack_bridge.c`, `net/netfilter/nfnetlink_queue.c`, `net/netfilter/xt_CHECKSUM.c`, `net/xfrm/xfrm_output.c`

Kernel lines with no fixed release (4.x, 5.4, 6.2–6.5, 6.7–6.11, 6.13–6.17, 7.0, 7.1, …) are affected unless the distribution backported the fix. The vulnerable IPv4 output code is always built in, so unloading modules or removing firewall rules is not a mitigation. Upgrading the kernel and rebooting (or applying a vendor live patch) is.

Quick start

# One host, locally
sudo ./check_cve_2026_99999.sh

# Many hosts over SSH
./scan_hosts.py -f hosts.ini --list-hosts      # 1. confirm the host list was read correctly
./scan_hosts.py -f hosts.ini -u root           # 2. scan

check_cve_2026_99999.sh

Requirements

bash 4.2 or newer (CentOS 7 and later), standard coreutils, awk, grep, sed
Root is recommended. Without root the verdict is still produced, but firewall rules, IPsec state and (on dnf/yum hosts) repository metadata may not be readable.

Usage

check_cve_2026_99999.sh [--json] [--refresh-metadata]
check_cve_2026_99999.sh --kernel <release> [--json]
check_cve_2026_99999.sh --help

Option	Meaning
(none)	Human-readable report for this host
`--json`	One JSON object on a single line (used by `scan_hosts.py`)
`--refresh-metadata`	Refresh the package repository metadata (`dnf --refresh`, `apt-get update`, zypper refresh, `checkupdates` on Arch) before looking for a fixed kernel. Without it only the local cache is read, which may be out of date.
`--kernel <release>`	Check only a version string, e.g. one copied from an inventory or CMDB. Nothing about the local host is checked.
`-h`, `--help`	Show the built-in help

Examples

sudo ./check_cve_2026_99999.sh
sudo ./check_cve_2026_99999.sh --refresh-metadata
sudo ./check_cve_2026_99999.sh --json > "$(hostname)-cve.json"

./check_cve_2026_99999.sh --kernel 6.6.150                       # AFFECTED
./check_cve_2026_99999.sh --kernel 6.12.113                      # NOT_AFFECTED
./check_cve_2026_99999.sh --kernel 5.14.0-427.13.1.el9_4.x86_64  # UNKNOWN (vendor kernel, see below)

Run it on a host without copying it there:

ssh root@kvm01 'bash -s' < check_cve_2026_99999.sh

Verdicts and exit codes

Verdict	Exit code	Meaning
`NOT_AFFECTED`	0	The kernel already has the fix: its version contains it, the vendor changelog lists the CVE, or a loaded live patch does
`AFFECTED`	1	Upstream-based kernel (Arch, Fedora, Debian, custom builds) whose version is older than the fix
`LIKELY_AFFECTED`	1	Vendor kernel (RHEL family, Ubuntu, Proxmox, SUSE, …) whose changelog was read and does not mention the CVE. Confirm with the vendor advisory.
`UNKNOWN`	2	Vendor kernel whose changelog could not be read, or a version string that could not be parsed. Check manually.
–	3	Usage error

How the verdict is reached

Upstream version. The kernel.org version the build is based on is worked out:
- Debian: from the package version (6.1.0-28-amd64 is really 6.1.119)
- Ubuntu: from /proc/version_signature
- Everything else: from uname -r
If that version contains the fix, the host is NOT_AFFECTED.
Backports. If the version is in the affected range, the kernel package changelog (rpm -q --changelog or /usr/share/doc/<pkg>/changelog.Debian.gz) is searched for CVE-2026-99999. A match means the vendor backported the fix.
Live patches. If any live patch is loaded, kpatch list, canonical-livepatch status and the matching kpatch-patch-* package changelog are searched for the CVE.
Otherwise the host is AFFECTED. For vendor kernels it is LIKELY_AFFECTED, or UNKNOWN if no changelog was available.

The same check is repeated for every kernel installed under /lib/modules. If a fixed kernel is installed but not running, the remediation says to reboot into it.

Finding the fixed-kernel target

When the running kernel is not fixed, the host's package manager is asked what newer kernel is available:

Package manager	What is checked	Suggested command
dnf / yum (RHEL, Rocky, Alma, Oracle, Fedora)	Errata listing the CVE (`updateinfo list --cve`), plus the newest `kernel` / `kernel-uek`	`dnf upgrade --advisory=<ID>`
apt (Debian, Ubuntu, Proxmox)	Upgradable `linux-image-`, `linux-generic`, `proxmox-kernel-`, `pve-kernel-*` packages	`apt-get install --only-upgrade <pkg>`
zypper (SLES, openSUSE)	Patches listing the CVE, plus the newest `kernel-default`	`zypper patch --cve=CVE-2026-99999`
pacman (Arch)	Newer `linux`, `linux-lts`, `linux-zen`, `linux-hardened`, `linux-rt`	`pacman -Syu`

Each candidate is labelled:

FIXES: a vendor advisory names the CVE, or the version alone proves the fix is included
NO_FIX: the version is still in the affected range (e.g. linux-lts 6.12.110 when 6.12.113 is needed)
UNKNOWN: a vendor version number that cannot be judged on its own. Check the vendor advisory (on Ubuntu: pro fix CVE-2026-99999).

The Target line shows the best candidate, and Remediation shows what to do: reboot into an installed fixed kernel, run the upgrade command, check an unverified candidate, or wait for the vendor because nothing fixed is available yet.

Reading the report

CVE-2026-99999 check - host kvm01 - 2026-10-18T08:58:20Z

  OS                : Rocky Linux 9.4 (Blue Onyx)
  Running kernel    : 5.14.0-427.13.1.el9_4.x86_64
  Upstream base     : 5.14.0
  Kernel package    : kernel-core-5.14.0-427.13.1.el9_4.x86_64
  Changelog search  : no-mention
  Live patches      : none

  VERDICT           : LIKELY_AFFECTED
  Reason            : branch 5.14 has no fixed stable release; vendor kernel changelog does not mention ...
  Target            : kernel 5.14.0-503.40.1.el9_5
  Remediation       : dnf upgrade --advisory=RLSA-2026:1234, then reboot

  Installed kernels:
    5.14.0-427.13.1.el9_4.x86_64             LIKELY_AFFECTED  (running)

  Available targets (dnf, metadata from local cache):
    kernel                       5.14.0-503.40.1.el9_5          FIXES    advisory RLSA-2026:1234

  KVM / exposure indicators (informational - the vulnerable IPv4 output path is always built in):
    /dev/kvm present             : yes
    ...

The KVM / exposure indicators section lists /dev/kvm, the KVM module, running QEMU processes, bridges, br_netfilter, nf_conntrack_bridge, nfnetlink_queue, xt_CHECKSUM, CHECKSUM/NFQUEUE firewall rules and IPsec (xfrm) states. These show which affected subsystems a host uses and can help decide which hosts to patch first. They do not change the verdict.

Most Popular

CVE-2026-99999-kernel-check