Linux Kernel Security Checklist: Is Your Server Actually Patched?

🗓️ Why check this now?

CVE-2026-99999 was published on 15 October 2026. It concerns Linux IPv4 packet handling. Red Hat describes a possible attack path from a local attacker or an untrusted guest into an affected host, with potential memory corruption and host impact.

That does not mean every public website is remotely exploitable. Check the affected environment and the vendor’s assessment before deciding what action your server needs.

Start with the system boundary. A physical server, a virtual machine, and a container do not have the same relationship with the kernel.

Run these commands on the system you are assessing. Save the results in your maintenance notes.

cat /etc/os-release
uname -r
uname -v

The uname -r command reports the running kernel release. It does not list every installed kernel and does not, by itself, prove whether a CVE is fixed.

On a system with systemd tools, this can help identify the environment:

systemd-detect-virt

Treat the result as a useful hint. Confirm the hosting model in your provider’s control panel or documentation. A result of “none” is not an error requiring a fix.

Match the advisory to your distribution, release, architecture, and kernel flavour. Cloud, generic, real-time, and hardware enablement kernels may have different package records.

Use the vendor’s fixed package version or erratum. Distribution vendors often backport security fixes into older version lines, so an older-looking kernel number does not automatically mean it is vulnerable.

Choose the command for your distribution. These examples list installed package information; they do not download or install updates.

Ubuntu and Debian package inspection

dpkg -l 'linux-image*'
uname -r

In the package list, ii indicates an installed package. Other states can include removed packages with configuration files left behind. Match the relevant package to the vendor’s advisory.

RHEL package inspection

rpm -q kernel kernel-core
uname -r

Package names vary across products and kernel flavours. A “not installed” result for one queried name is not enough to determine patch status.

If a fix is available and missing, install it through the supported procedure for your distribution and change policy. Review the transaction and any required service or boot changes before proceeding.

A conventional kernel update normally requires booting the corrected kernel. Before rebooting a remote server, make sure you can recover access.

• Confirm that the provider console or other out-of-band access works.
• Check current backups and the recovery procedure. A snapshot alone may not be an application-consistent database backup.
• Record the running kernel and current service health.
• Check free space in the relevant filesystems, including /boot if it is separate.
• Review critical jobs, traffic, and the maintenance window. Drain workloads where your platform requires it.
• Keep an appropriate recovery option. A previous kernel can help recover a failed boot, but may still contain the vulnerability.

df -h

On Ubuntu systems, a reboot-required marker may provide an additional signal:

if [ -f /run/reboot-required ]; then
    cat /run/reboot-required
else
    printf 'No reboot-required marker found.\n'
fi

A missing marker is not proof that this CVE is fixed. Use the package, running kernel, and advisory together.

Reconnect and inspect the running kernel again. Compare the result with the package and advisory you recorded.

uname -r
uname -v
uptime

On a systemd-based host, check failed units and current-boot warnings:

systemctl --failed --no-pager
sudo journalctl -b -p warning --no-pager

Warnings need context. Some may predate the update or be harmless in your environment. Compare with the baseline rather than treating every line as a new failure.

A page that loads and an empty failed-unit list are useful health signals. Neither is a vulnerability assessment on its own.

Save a short maintenance record. It should identify the system, advisory, package, active kernel or live patch, check time, and application result.

If something is unresolved, name it plainly. “Waiting for a vendor fix” and “provider confirmation pending” are useful statuses. They should not be recorded as “patched.”