The number in the subject line is the trap. Marcus Nestor’s Oct. 2 report at 9to5Linux says Debian shipped a kernel security update on Sept. 29 for Debian 13 “Trixie” that addresses 1,313 vulnerabilities, and that the fixed package is linux 6.12.111-1. Philipp Esselbach’s Oct. 3 roundup at Linux Compatible has a cousin number: Ubuntu’s USN-8816-4 puts 101 CVEs on the Google Container Engine kernel for 26.04 LTS. I am writing this as a patch order, not as a siren. A four-digit CVE count can be a packaging decision. A Critical on a remote-desktop library is a different kind of item, and it should not wait behind the four-digit one just because 1,313 is a louder digit.
We wrote a single Ubuntu kernel CVE that mattered because of how containers see the host in CVE-2026-80521, check the kernel, not Docker. We wrote a deadline that had already passed in CISA’s kernel KEV date. We wrote a driver floor that was a version check, not a vibe, in NVIDIA’s Sept. 30 list. This week is the batch update those habits were for.
The 1,313 figure is how Debian packs a kernel, not how many fires you have
Nestor’s explanation is the part worth keeping next to the number. Debian Stable does not ship every upstream stable point release as its own Debian Security Advisory. Fixes accumulate across several upstream kernel versions and land in a larger periodic update. A longer gap makes a bigger batch. The other reason he gives is a policy change in how kernel CVEs are assigned: a commit identified as fixing a potential security issue can get a CVE even when the issue is minor or has no known exploit path. Both reasons can be true. Neither of them means you can ignore the package.
The advisory text, which 9to5Linux quotes from the Sept. 29 debian-security-announce message, is the old sentence. Several vulnerabilities in the Linux kernel may lead to a privilege escalation, a denial of service, or an information leak. For trixie, the problems are fixed in 6.12.111-1. The project recommends upgrading the linux packages. Nestor’s own caution is the sentence I would paste into the change ticket: seeing more than 1,300 CVEs in one update is overwhelming, the vast majority are low-severity or highly conditional or tied to a subsystem your machine does not use, and the update is still worth applying. It is not 1,313 independently critical issues.
The command he prints is the one I will print, and I will not add flags he did not.
sudo apt update && sudo apt full-upgrade
Then reboot. A kernel package that is installed and not running is a changelog, not a fix. I have skipped that reboot on hosts that “looked fine” and then spent a week debugging a module that was built against the previous ABI. This week’s Ubuntu notes make that mistake explicit. Debian’s note, via 9to5Linux, stops at update and reboot. Do the reboot before you congratulate the playbook.
If you are not on Trixie, this version string is not your version string. 6.12.111-1 is the trixie package Nestor is writing about. I am not going to tell a bookworm admin to pin that version because a headline said 1,313. Read the advisory for the suite you actually run. The habit is the same. The package name is not.
USN-8816-4 is a GKE image backlog, and the ARM bug is the one with a mechanism
Esselbach’s Oct. 3 roundup treats USN-8816-4 as the loud Ubuntu item and then tells you not to panic at the digit. One hundred and one CVEs, 38 subsystems, on the Google Container Engine kernel for Ubuntu 26.04 LTS. InfiniBand, NVMe, SMB, the IPv6 stack. Most of those CVEs already lived upstream. His reading, which I am borrowing because it matches the shape of the Debian batch, is a cleared backlog rather than a fresh emergency. A GKE image is also not every laptop. If you do not run that image, do not spend the morning hunting USN-8816-4 on a desktop and calling it the same patch.
The notices he groups next are older releases, and they share three flaws rather than 101. USN-8851-2 covers Raspberry Pi on 18.04. USN-8864-1 covers 16.04 and 14.04. Both, in his summary, patch the NFS server daemon, IPv6, and Netfilter under CVE-2025-38724, CVE-2025-53131, and CVE-2025-53221. USN-8818-6, the 22.04 FIPS notice, layers about a dozen more on top, and CVE-2025-53221 shows up again there. The year in those CVE ids is 2025. That is the backlog point in numeric form. An October 2026 notice can be the first time your image actually carries a fix that upstream dated last year. Late is still the correct time to install it. It is not evidence that a new worm started on Thursday.
The single bug he says earns attention is CVE-2025-10263. Certain ARM chips can finish a broadcast TLB invalidation before memory writes through that mapping are globally visible. A local attacker can write to memory after permission was revoked. He calls the window small and the other side of it privilege escalation. I do not have a proof-of-concept in this roundup, and I am not going to go find one to paste. What I have is a condition: ARM, local, a permission check that the hardware can outrun. If your fleet is Intel in a rack, this is not today’s first patch. If you run ARM images, including a pile of cloud instances that are ARM now and were an afterthought in the spreadsheet, put this CVE on the ticket next to the reboot, not in the “101 CVEs, whatever” pile.
Every notice in that Ubuntu batch, Esselbach writes, closes the same way. Update, reboot, and recompile any third-party kernel modules, because the ABI change is unavoidable. Metapackages usually do the rebuild. Not always. Several of the notices also sit behind Ubuntu Pro. An unattended-upgrade run that skips Pro pockets will report a clean host that is not clean. Check the pocket before you trust the green check.
freerdp is the Critical, if remote desktop is anywhere near the box
The item Esselbach says to patch before the rest of the Red Hat batch is FreeRDP. RHSA-2026:73979 rates it Critical for RHEL 10. Rocky Linux 10 has the matching RSA-2026:73979 at the same severity. His condition is practical: if remote desktop protocols touch anything near production, this goes on before the kernel trivia. The roundup does not print a CVE id for that FreeRDP flaw in the section I am using. I am not going to borrow one from memory or from a different week. The advisory ids are enough to find the errata. The severity is the reason it outranks a 101-count backlog.
I would not “while I’m here” this onto a Debian laptop that has never run xfreerdp. The Critical is about a library you are running, not about a brand you have heard of. If an admin jumps to a workstation and leaves an RDP session up for a vendor, that workstation is in scope. If the only FreeRDP binary on the estate is in a test container nobody starts, write that down and do the kernel reboot first. Scope is the whole job. The roundup is a menu. It is not an order to install every package named in it.
The rest of his Red Hat list is a calendar, and I am not going to promote it. Ruby and a kpatch set land at Important on RHEL 10. There is a kernel update NVIDIA-tagged for RHEL 10. On RHEL 8, gawk is Moderate. Ghostscript is Moderate on RHEL 9. He also warns that a Satellite advisory title says Critical while the body says Important, on a 6.17.12 item. Read the body. I have shipped the wrong urgency off a title before, and this roundup is explicitly telling you the title can lie.
Firefox, redis, and the fix that broke Evolution
Debian’s non-kernel batch in the same Oct. 3 roundup has two packages he pulls out of the pile. Firefox ESR jumps from the 140 series to the 153 series with 62 CVEs attached. The outcomes he names are arbitrary code execution, sandbox escape, and privilege escalation. Debian 12 bookworm gets 153.4.0esr-1deb12u1. The Freexian track for Debian 11 bullseye gets 153.4.0esr-1deb11u1. A browser on a server is often a leftover. A browser on an admin workstation is how the CSRF and the stolen session actually arrive. If the workstation is Debian and Firefox ESR is the browser, this is not optional color next to the kernel number.
redis is the other one that can bite, in his wording. DSA 6538-1 bundles four CVEs and a set of bugs that did not all get CVE ids. ACL checks can be skipped across SORT, GEORADIUS, and XREAD. There is an out-of-bounds read, a use-after-free, and an integer overflow in HyperLogLog. Trixie stable gets 5:8.0.2-3+deb13u3. If Redis is bound to localhost and a password, you still patch it. The ACL skip is the kind of bug that matters exactly when you thought the ACL was the control. I am not going to rank it above the kernel reboot on a host that does not run Redis. I am going to rank it above a leisurely “next maintenance window” on a host that does.
The webkit2gtk note is the caution, and it is funnier than a CVE list deserves. DSA-6534-1 introduced regressions that crashed Evolution and Eclipse on startup. DSA-6534-2 fixes the fix. Esselbach’s point is that they caught it. Mine is operational. If you rushed the previous webkit advisory and your mail client or your IDE died on launch, you are not imagining it, and the follow-up advisory is the repair. Patching is not a moral state. It is a package version. Sometimes the next version is what makes the machine usable again. Check which DSA you actually installed before you tell a user to reinstall Eclipse from scratch.
The order I would run, on a Debian 13 host that also sits near the packages in this roundup, is short. Apply 6.12.111-1, reboot, confirm uname -r moved. If FreeRDP is in the path on a RHEL or Rocky 10 box, do that errata before you admire the kernel changelog. If Firefox ESR or Redis is present, take the versions above. If you are on the Ubuntu GKE image, USN-8816-4 is your kernel item, and it is a backlog, not a new worm. If you are on ARM, read CVE-2025-10263 before you file the 101 CVEs as noise. Then write down the reboot. The CVE count is not the work. The kernel that is actually running is.