Skip to content

How to Read a CVE on Raspberry Pi OS and Ubuntu

A CVE is an identifier for a publicly disclosed vulnerability, not a verdict about your computer. To decide what to do, match the affected component, your package provider and the conditions needed to reach the bug.

This guide gives you a repeatable way to read an advisory before changing a working Raspberry Pi or Ubuntu system.

Four terms you need

  • Vulnerability: a flaw that can break a security boundary under particular conditions.
  • CVE: the shared identifier used to discuss that flaw across vendors and tools.
  • CVSS: a severity assessment with stated assumptions, not the probability that your Pi will be attacked.
  • Security advisory: the vendor's explanation of affected products, available corrections and required action.

The Ubuntu CVE guide explains how its release/package statuses and priority levels work. A vendor priority and a CVSS score answer different questions; do not treat a different label as proof that one source is wrong.

1. Identify the component and attack conditions

Is the flaw in the Linux kernel, OpenSSH, a browser, a library or an application you installed? Then ask what an attacker needs: a network connection, a local account, an untrusted file, a guest VM, or administrative access.

A severe bug can be unreachable in one configuration and important in another. Conversely, a service that is not exposed to the Internet can still be reached by an untrusted local workload. Separate affected code from a reachable attack path; neither a board name nor a firewall alone answers both questions.

2. Identify who supplies the affected package

Raspberry Pi OS, Debian and Ubuntu share software, but do not necessarily ship identical packages or fixes. Ubuntu also has different kernel families, including Raspberry Pi-specific kernels. Read the status for your release and package, not just the first green row in a vendor table.

Backporting means applying a correction to an older maintained software branch. An older-looking version can therefore contain a fix. Comparing only uname -r with an upstream version is not a complete vulnerability check. Ubuntu explains the principle in its security-update documentation; for a particular CVE, use its package-specific advisory and fixed version.

Run this read-only check on the machine you administer, not just inside a container:

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

os-release identifies the distribution/release, uname -r reports the running kernel, and dpkg reports the package architecture. A container usually shares the host kernel, so its Ubuntu user-space label is not enough to identify the host's kernel package.

3. Read the status, not just a version number

  • Affected / vulnerable: the vendor identifies the package as needing a correction. Check which release and attack conditions apply.
  • Fixed / released: a correction is available for the named package stream. Check the installed package and whether a restart is required.
  • Not affected: applies to the specific product/release evaluated, not every related distribution.
  • Pending / work in progress / under investigation: do not assume a candidate build is already published or that investigation means safety.

Keep upstream fixes, vendor-package availability, local installation and activation as four separate checkpoints. On Ubuntu, Security Notices describe released fixes. On Raspberry Pi OS, use the supported APT update procedure; do not substitute a pre-release firmware tool merely to obtain a larger version number.

4. Update deliberately and check activation

Prepare a backup, free space and a recovery path before administrative changes. Review the proposed package changes; do not remove a working kernel or switch repositories just because a blog mentions a newer upstream release.

Installing a new kernel does not normally replace the kernel already running. Arrange a reboot when the vendor requires it, reconnect, and match the running kernel to the installed corrected package. Other fixes may require a service restart instead. Do not assume that an available live-patching service covers a particular CVE or kernel.

An update command completing successfully is evidence that the update operation completed, not a universal “this CVE is fixed” result. If the exact vendor/package status remains unknown, record it as unknown and seek the provider's guidance.

Check your understanding

Your Pi reports a kernel version older than the upstream fix. Is it definitely vulnerable? Not from that fact alone: check whether its provider backported the correction and whether that corrected kernel is running.

A vendor lists a fixed package. Is your Pi definitely protected? No: availability, installation and activation are separate.

Continue with CVE-2026-99999 explained, or return to Security.

Donate