Debian patched 1,313 kernel CVEs at once. Most are noise. Some aren't.

1,313. That is the number of CVE entries in Debian’s September 29 kernel security advisory, DSA-6528-1. The kernel package for Debian 13 (Trixie) ships as version 6.12.111-1. The advisory spans three years of CVE identifiers, 2024 through 2026, across every subsystem Debian maintains a backport for.

The tech press treated this as a fire alarm. It isn’t. It’s a plumbing bill that has been sitting on the counter for six months.

What Debian’s “stable” policy actually means

Debian stable is not “current.” It is “tested, frozen, and backport-maintained.” The moment Debian freezes a release, the kernel version is fixed. Security fixes don’t flow in via rolling kernel version bumps. They flow in as targeted backports from the upstream stable-rc tree, reviewed by the Debian kernel team and applied to a base that may be eighteen months behind mainline.

1,313 CVEs means the upstream kernel security team identified, triaged, and fixed 1,313 flaws across roughly three years of development. Debian’s packagers backported those fixes, tested them against the frozen 6.12 base, and shipped the batch.

This is the correct behavior for a stability-first distro. The alternative is shipping every kernel point release and calling that “stable.” That is what Arch does. Pick your model and live with its consequences.

What is actually in the 1,313

Not every entry is equal. Based on the subsystem breakdown in the advisory and the severity distribution typical of large Debian kernel batches, roughly 60 to 70 percent are CVSS 4.0 or lower: theoretical races in obscure driver paths, NULL check omissions in hardware code that hasn’t shipped anything relevant since 2019, off-by-ones in filesystems not mounted by default anywhere. They get CVEs because the CVE numbering process is thorough, not because they represent meaningful exposure.

Another 20 to 25 percent are medium severity: local privilege escalation requiring specific setup, information leaks from kernel memory given local access, DoS via crafted input to subsystems not exposed in most deployments.

The remaining 5 to 10 percent are the ones worth reading carefully. Heap overflows. Use-after-free bugs. Privilege escalation in widely deployed subsystems.

In this batch: CVE-2026-31402 is a heap overflow in nfsd. CVE-2026-31504 is a use-after-free in the network fanout path. CVE-2026-43503 touches dirty page fragment handling. If you are running NFS exports, or anything that uses socket fanout for packet distribution, patch before your next maintenance window rather than after.

Everything else: apply on your normal cycle. The number is large because Debian batches. The actual risk surface is what it always is.

The number is not the problem

If you want to be irritated about something, direct it at the CVE assignment process. As the CVE scoring inflation problem has made clear, a large fraction of what gets assigned a CVE number today would not have qualified under criteria in place a decade ago. The infrastructure for issuing CVE numbers scaled faster than the discipline for deciding what deserves one.

The kernel itself is a different question. A 30-million-line codebase with 1,500 active contributors processes somewhere around 8 to 10 commits per hour, every hour, continuously. A fraction introduce defects. A fraction of those defects meet the bar for a CVE. Over three years of development, 1,313 is not surprising. It is arithmetic.

The io_uring structural CVE work from August is the kind of story that actually represents architectural security debt. io_uring outgrew its original security model and required real design changes to fix. Most of the 1,313 are not that. Most are the normal attrition rate you get when humans write systems software at this scale, found and fixed in the normal course of kernel development.

Patch and get on with it

Apply DSA-6528-1 on whatever schedule you use for security updates. If you have Debian Trixie boxes running NFS servers or socket fanout, front-load those. The nfsd heap overflow is real and the UAF in the fanout path is exploitable given network access to the right socket configuration.

If 1,313 CVEs in a single advisory gives you existential dread about Linux kernel security, the useful place to put that energy is threat modeling your actual deployments. A box running NFS with full socket fanout enabled and no kernel lockdown is a different risk than a VM running nothing but a Postgres socket behind a firewall. The CVE count is per-distro-per-batch. Your attack surface is per-machine-per-configuration. Know the difference.