432 Linux kernel CVEs in 38 hours: the count is policy, not new attacks

Between 9:09 a.m. on July 19 and 4:27 p.m. on July 20, the Linux kernel's official CVE feed pushed 432 published security advisories, each a publicly catalogued security flaw with a unique ID. The bulk of the batch was memory-safety fixes for networking drivers, filesystems, and memory management. Most readers will see "432 vulnerabilities in two days" and read it as a new attack wave. The kernel team's own explanation is closer to a definitional firehose than a security emergency.

The trigger was a thread on the oss-security mailing list, started Monday by Jan Schaumann, Akamai's chief information security architect. After nixCraft first flagged the volume on Monday morning, Schaumann escalated it to the public list and asked the obvious reader question: is this an attack surge, or is the intake just louder than the underlying code? Greg Kroah-Hartman, who runs the kernel's stable releases and signs off on its CVE assignments, pushed back on the surge framing: the kernel team follows the CVE Program's definition, and at the kernel level almost any bug affecting a running system can be classified as a vulnerability, including memory-safety fixes that would be invisible in many other projects.

Linus Torvalds flagged the same dynamic in May, calling the linux-cve mailing list "almost entirely unmanageable" because AI-powered bug-hunters had moved from noise to contributors. Earlier in 2026, Kroah-Hartman told The Register the AI reports had become worthwhile and predicted they would keep adding to his workload. The July 19–20 batch is the 432-number version of that prediction.

The Register's breakdown and secondary coverage from gbhackers and HackersOnlineClub lay out the subsystem spread: networking drivers (Netfilter, the mlx5e Mellanox driver, Qualcomm RMNET), filesystems (XFS, Btrfs), memory management, Bluetooth's L2CAP and BNEP layers, KVM and SEV virtualization, the ksmbd and CIFS SMB stacks. Flaw types are the usual kernel fare: use-after-free, NULL-pointer dereferences, out-of-bounds reads and writes, race conditions, reference-count leaks, integer underflows. Specific IDs include CVE-2026-64188 (a Qualcomm RMNET use-after-free), CVE-2026-64122 (mlx5e use-after-free), CVE-2026-64074 (a statmount slab out-of-bounds read), CVE-2026-64102 (an RDMA/siw MPA integer underflow), CVE-2026-64024 (a TCP initial-sequence-number leak), CVE-2026-64114 (an IPv4 HDRINCL issue), CVE-2026-64206 (Bluetooth L2CAP), CVE-2026-64178 (Bluetooth BNEP), and CVE-2026-64138 (CIFS ACL). Fixes are already merged into upstream stable kernels; the question is when they reach the distribution kernels most servers and devices actually run.

On the same thread, Schaumann proposed two options: point an LLM at the intake to prioritize, or wait to see which of the 432 actually show up in the wild. The first half is a triage proposal, not adopted kernel-team policy. Kroah-Hartman's follow-up on the same thread holds the line on definition: the count is a function of what counts as a vulnerability, not of new attack volume. Marcus Meissner of SUSE added to the thread with the distribution-perspective point that most of these only become user-visible after distros turn them into package advisories on their own cadence.

Two layers separate the 432 number from a patch a reader can install. The kernel feed is the authoritative count and the right place to look up individual advisories; distro security pages are where these become installable patches. The number a distribution ships in its next security rollup will be smaller than 432, because the distribution decides which of the kernel-side advisories to backport and at what severity, and that decision is not visible in the upstream CVE list. The intake is loud; the patch queue is the reader-facing surface.

If the kernel team tightened its policy tomorrow, narrowing "vulnerability" to flaws with a security-boundary crossing instead of any memory-safety bug affecting a running system, the headline number would drop sharply without the code itself getting safer. That is the test "CVE count equals security state" fails, and it is the kernel team's own position. The next stable kernel cutoff, and the round of distribution advisories that pull from it, are the watch item that matters more than the 432 figure. The count is a measure of the intake, not a measure of the threat.