Skip to content

CVE-2026-99999 Explained: Should Raspberry Pi and Ubuntu Users Worry?

Check your kernel provider and workload, but do not assume every Internet-connected Pi is remotely exploitable. CVE-2026-99999 concerns Linux IPv4 checksum handling; the official record describes a guest/local virtual-network path, not ordinary Internet reception. A virtual machine is a software-defined computer; its host is the system running it.

This article explains that distinction, provides read-only package checks, and separates a published fix from an update actually running on your machine. Last reviewed: 30 October 2026.

CVE-2026-99999: what goes wrong?

A checksum helps detect damaged network data. Linux can carry internal metadata saying where checksum work should happen. In this bug, an invalid position can cause checksum processing to overwrite data it should not change.

The documented scenario starts with an untrusted guest supplying malformed virtual-network metadata. Host-side processing can then corrupt kernel memory, with consequences including disclosure, crashes or code execution. The Linux-maintained CVE record describes the conditions; this guide does not reproduce them.

flowchart TD accTitle: Guest input crossing into the host kernel accDescr: An untrusted virtual machine supplies virtual network metadata. The host kernel processes it, and a validation flaw can affect host memory. This is not a diagram of ordinary Internet packet reception. A[Untrusted guest VM] -->|Virtual network metadata| B[Host Linux network processing] B -->|Invalid checksum position| C[Kernel memory corruption] C --> D[Host data or service affected]

The important boundary is guest → host, not merely “one computer sends a packet to another.” A network-related kernel bug is not automatically an unauthenticated remote attack against every open port.

Who should investigate first?

Prioritise hosts that run untrusted VMs or sandbox workloads using the relevant virtual-network path. If you rent a VM, the provider must address its host kernel; updating inside your guest does not patch the provider's host.

An ordinary Pi used for your own trusted applications is a different deployment. That does not prove its kernel is fixed or that every other local path is impossible. Likewise, “I do not use KVM” is not a package-level unaffected verdict. Use the vendor assessment for your exact kernel and configuration.

Do not rely on closing an HTTP port, disabling SSH, or turning off IPv4 as a verified correction for this flaw. Those actions may break access without addressing the documented boundary. Avoid downloading an unknown “CVE scanner” or running exploit code on a working Pi.

OS-specific status on 30 October 2026

Ubuntu: check the kernel family as well as the release

The Ubuntu CVE page listed linux-raspi for Ubuntu 22.04 LTS, 24.04 LTS and 26.04 LTS as vulnerable at review time. Other kernel families have their own rows. Ubuntu displayed CVSS 9.3/Critical alongside its own Medium priority; these are different assessments, not a statement that all installations face the same exposure.

Read the current row before taking action. A “work in progress” build is not a released fix, and a fixed linux row does not automatically cover linux-raspi, HWE or a cloud kernel.

Debian: fixed packages are recorded

The Debian tracker recorded fixes for the linux source package in Bookworm security version 6.1.190-1 and Trixie security version 6.12.113-1. These are Debian package-stream examples, not minimum-version rules for every kernel. The tracker also lists separate streams such as Bookworm's linux-6.12.

Raspberry Pi OS: not verified fixed here

This review does not establish a Raspberry Pi OS fixed package for this CVE. Raspberry Pi OS is Debian-based, but its Raspberry Pi kernel builds need their own package/source evidence. Neither a Debian fixed row nor an Ubuntu vulnerable row can simply be copied into a Raspberry Pi OS verdict.

If the exact correction cannot be established, record “fix status not verified”, keep supported updates current and ask the package provider or system administrator about that build. Unknown is not the same as unaffected.

1. Identify the running system and installed kernel packages

Run these read-only commands on the host you administer. They do not trigger the vulnerability or install anything:

1
2
3
cat /etc/os-release
uname -r
dpkg --print-architecture

uname -r is the running kernel, not a list of everything installed. Next, list installed kernel image packages and their source versions:

1
2
3
4
5
6
7
8
(
    set -o pipefail
    printf 'PACKAGE\tINSTALLED\tSOURCE\tSOURCE_VERSION\n'
    dpkg-query -W -f='${db:Status-Abbrev}\t${binary:Package}\t${Version}\t${source:Package}\t${source:Version}\n' |
        awk -F '\t' '$1 ~ /^ii/ && $2 ~ /^(linux-image-|raspberrypi-kernel(:|$))/ {
            print $2 "\t" $3 "\t" $4 "\t" $5
        }'
)

The filter shows fully installed packages with these common kernel names; an empty result is not an unaffected verdict. If the command reports a package-query error, resolve that before using the inventory. Custom kernels and other naming schemes need their own inventory. Multiple rows can include old kernels and metapackages that track the current image. Do not assume the newest listed package is running.

SOURCE identifies a source-package name, not its repository owner. Raspberry Pi and Debian builds can both call their source linux. For one exact image package from your output, inspect repository information (replace the placeholder):

1
2
image_package=REPLACE_WITH_EXACT_IMAGE_PACKAGE_NAME
apt-cache policy "$image_package"

Check the installed version, candidate version and repository URLs. This uses the local APT cache, which may be stale. If an installed version no longer appears in a repository, its origin may need further records. Do not share private repository URLs or credentials in public support posts.

Match the distribution + release + kernel family + full package version against the provider's current CVE/advisory. Upstream version comparisons alone miss backported corrections; see How to Read a CVE.

2. Install supported updates, not an arbitrary kernel

These are administrative changes, not diagnostic commands. Back up important data, check free space, arrange recovery access and plan downtime first. Do not update the host of important VMs without an appropriate maintenance plan.

For Raspberry Pi OS, follow its supported APT procedure:

1
2
sudo apt update
sudo apt full-upgrade

For Ubuntu, follow its security-update instructions and any notice for your kernel:

1
2
sudo apt update
sudo apt upgrade

Stop if refreshing package lists fails. Review proposed changes before approving; if a kernel is held back, investigate the dependency or hold rather than removing the working kernel. Neither command proves this CVE is corrected if your provider has not published the relevant fix. Do not switch release repositories, install an unrelated Debian/Ubuntu kernel on Raspberry Pi OS, or use rpi-update as a routine CVE repair.

If no fix is available, assess untrusted workloads with the administrator/provider and follow their mitigation guidance. This article offers no independently validated workaround. Do not infer Livepatch coverage from a subscription or service name alone.

3. Verify after the required reboot

Installing a kernel normally leaves the previous kernel running until reboot. During planned downtime, save work and use your normal shutdown/reboot procedure. On a remotely managed system, first make sure you can recover if it does not return.

After reconnecting, rerun the read-only inventory above. Confirm:

  • The corrected package belongs to the intended provider, release and kernel family.
  • The corrected image is actually running, rather than merely installed.
  • Required networking, storage, applications and VMs still work.
  • Your evidence is a released advisory/source correction and package match—not just “APT finished” or a larger kernel number.

If a temporary rollback is required for a boot failure, follow your documented recovery procedure; returning to an affected kernel also returns its security risk. Do not delete your only working recovery option while troubleshooting remotely.

Verification scope and open questions

On 30 October 2026, the read-only inventory was checked on a Raspberry Pi 4 Model B Rev 1.5, Debian GNU/Linux 13 (Trixie), running 6.18.50+rpt-rpi-v8 on arm64. The image package reported 1:6.18.50-1+rpt1 and source name linux.

This confirms that the inventory commands work on that installation, not that its CVE status is determined. No exploit, kernel upgrade, reboot or VM escape test was performed, and no Ubuntu device was tested. A Raspberry Pi OS fixed-build determination remains open.

References and revision history

  • Official CVE record: vulnerability and documented attack scenario.
  • NVD entry: cross-reference; NVD scoring/enrichment can differ from the assigning authority.
  • Ubuntu package status and Debian package status: check live records before relying on this dated snapshot.
  • 30 October 2026: first review; read-only Pi inventory verified; OS-specific limits recorded above.

Return to Security or review CVE basics. For routine prevention rather than this specific flaw, use SSH and firewall hardening.

Donate