Why Debian kernel advisories list hundreds of CVEs, and how to prioritise kernel updates and reboots

Open a recent Debian kernel advisory and the CVE list scrolls for pages. DSA-6528-1 for Debian 13 (trixie) on 29 September 2026 lists 1,311 CVEs; DLA-4817-1 for the 6.12 kernel on Debian 12 (bookworm) a few days later lists 1,312. That does not mean the kernel suddenly became a thousand times less safe. It reflects how kernel CVEs are now assigned, and it changes how you should handle kernel updates.

Why the lists got so long

In February 2024 the Linux kernel project was accepted as a CVE Numbering Authority (CNA), so the kernel developers now assign CVEs for kernel issues themselves. The kernel's CVE documentation explains the policy in plain terms:

• Because of where the kernel sits, "almost any bug might be exploitable", but that is often not evident when the bug is fixed. The assignment team is therefore "overly cautious" and assigns CVE numbers to any bug fix it identifies as potentially security-relevant, which "explains the seemingly large number of CVEs".
• CVEs are assigned after a fix is available in a stable kernel tree, and tracked by the commit of that fix.
• The kernel team does not judge whether a CVE applies to your system: "large numbers of assigned CVEs are not relevant" for any one system, since each uses only part of the source tree.
• The recommended approach is to take all released kernel changes, tested together, rather than cherry-picking individual fixes.

Debian follows the same approach. Its kernel updates move to newer upstream stable releases; DLA-4850-1, for example, notes that it "additionally includes many more bug fixes from stable updates 6.12.112 and 6.12.113". Every CVE attached to those stable releases ends up in the advisory, and Debian sums up the impact as "privilege escalation, denial of service or information leaks".

What this means for risk

You cannot triage a thousand CVEs one by one, and you do not need to. Treat each kernel update as a single package of fixes to install. Then decide how fast to install it based on a few signals:

• Known exploitation. Check whether any kernel CVE is in the CISA KEV catalog. In September and October 2026 CISA added four kernel CVEs: CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266 on 18 September, and CVE-2026-46300 on 28 October. Debian's tracker shows all four had already been fixed for trixie and bookworm in earlier updates. Servers that were patched and rebooted regularly were covered before the listing; servers that skipped updates were not.
• Network reachability. Some fixes concern code that remote traffic can reach. CVE-2026-72463, fixed in DSA-6568-1 and DLA-4850-1, is a use-after-free in the IPsec (xfrm) receive path that the kernel CNA scored 9.8 and describes as reachable by remote IPsec packets on VPN gateways using VTI or xfrm interfaces.
• Who can run code on the machine. Most kernel flaws need local access. On shared servers, CI runners, multi-user systems and container hosts running untrusted workloads, local means "any tenant", so these machines deserve faster updates.
• Features you actually use. A flaw in a file system you do not mount matters less than one in your network stack. This can lower urgency, but it is not a reason to skip an update.

A practical kernel routine

1. Install kernel updates promptly with sudo apt update && sudo apt upgrade. Debian kernel package names change with each ABI, so use apt upgrade or apt full-upgrade; according to its manual page, apt-get upgrade never installs packages that are not already installed, and can therefore hold the new kernel back.
2. Reboot on a schedule. A new kernel only protects you after a reboot. Pick a regular window (for example monthly) and an emergency path for KEV-listed or network-reachable flaws.
3. Confirm the running kernel after each reboot:

uname -r
dpkg -l 'linux-image-*' | grep '^ii'
sudo needrestart -k

uname -r shows the running kernel version, which matches the name of the installed linux-image-... package; needrestart -k reports only whether the running kernel is obsolete.

4. Reboot in rotation where you have redundancy (several web nodes behind a load balancer, database replicas), so you never take everything down at once.
5. Keep one previous kernel installed until the new one has booted cleanly, so you can pick it from the boot menu if a driver regresses.

Virtual machines and containers

A virtual machine runs its own operating system and kernel. On a VPS, the provider's work on the physical host does not replace the kernel inside your server: if your VPS runs Debian, the Debian kernel inside it is yours to update and reboot.

Containers are the opposite. As Docker's documentation puts it, multiple containers "all share the same kernel", and its security guide notes that container isolation can be incomplete in combination with kernel vulnerabilities. Rebuilding a container image does not change the kernel it runs on; only updating and rebooting the host (or the VM the containers run in) does.

Pitfalls

• Installed but not running. A server can have the newest kernel package for months while still running the old one because nobody rebooted.
• Held-back kernels when updates are run with apt-get upgrade, or when a linux-image-* metapackage is missing so new versions are never pulled in.
• Full /boot partitions on older installations, which can make kernel installation fail.
• Unsupported releases. Debian 11 (bullseye) no longer receives kernel updates since its LTS ended on 31 August 2026.

What you should do

• Install every Debian kernel update rather than evaluating CVEs one by one.
• Reboot on a fixed schedule, and faster for KEV-listed, network-reachable or multi-tenant risks.
• Verify the running kernel with uname -r after each reboot.
• Patch the kernel inside each VM, and the host kernel under your containers.
• Follow debian-security-announce (trixie) and debian-lts-announce (bookworm) so you know when a kernel update lands.

Sources

• docs.kernel.org/process/cve.html
• kroah.com/log/blog/2024/02/13/linux-is-a-cna
• debian.org/security/2026/dsa-6528
• security-tracker.debian.org/tracker/DSA-6528-1
• security-tracker.debian.org/tracker/DLA-4817-1
• security-tracker.debian.org/tracker/DLA-4850-1
• security-tracker.debian.org/tracker/DSA-6568-1
• security-tracker.debian.org/tracker/source-package/linux
• security-tracker.debian.org/tracker/CVE-2025-39964
• security-tracker.debian.org/tracker/CVE-2026-53266
• cve.org/CVERecord?id=CVE-2026-72463
• cve.org/CVERecord?id=CVE-2025-39682
• cve.org/CVERecord?id=CVE-2026-46300
• cisa.gov/known-exploited-vulnerabilities-catalog
• kernel-team.pages.debian.net/kernel-handbook/ch-versions.html
• manpages.debian.org/trixie/apt/apt-get.8.en.html
• manpages.debian.org/trixie/needrestart/needrestart.1.en.html
• docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container
• docs.docker.com/engine/security
• debian.org/News/2026/20260831