Microsoft's AI-assisted scan found Linux kernel bugs averaging 8.1 years old, so track the running kernel

Microsoft says its AI-assisted kernel scan found Linux bugs averaging 8.1 years old, and one lab root exploit needs no user namespaces, so we rank patch tracking and local-root detection level with cutting attack surface. A first public patch took a median of 41 days to reach a mainline release, before any distribution backport or your reboot.

What happened

Microsoft's FORGE Lab said on Nov. 11 that its AI-assisted scan, codename MDASH, covered a subset of kernel subsystems, such as networking, filesystems and security modules, from late May to mid-June 2026. Microsoft's own figures: 26,502 raw findings, 11,769 candidates, 621 with proof-of-concept evidence, 59 public upstream reports, 33 CVEs, 24 rated High or above. AI models did the code scanning and agents helped draft initial fixes; experts reviewed the 621 to find root causes and merge duplicates, and Microsoft said human validation and work with maintainers stayed essential.

Microsoft said it confirmed local root exploits for eight CVEs "in controlled laboratory environments, with some cases requiring non-default settings or disabled exploit mitigations." It does not say which of the eight needed those conditions. Fixes for 38 reports are merged into mainline, half on first submission; by our arithmetic 21 are not. As of Nov. 12, no report of exploitation appears in Microsoft's post, the kernel CVE records or Debian's tracker.

The average bug was 8.1 years old at first public report. Microsoft calls CVE-2026-74544 (the cls_u32 traffic classifier) one of the oldest, "at least 21 years"; its kernel record lists fixes in the 6.1, 6.6, 6.12 and 6.18 lines. Microsoft wrote that reaching a mainline release "from the first public patch took a median of 41 days (up to 108 days)."

Who is affected

Linux servers, Kubernetes nodes and CI runners on distribution or LTS kernels. The age is an average: not every bug is in every kernel. As of Nov. 12, Debian's tracker lists the Debian 12 security kernel 6.1.190-1 as vulnerable to CVE-2026-74544. The kernel CVE record for CVE-2026-98364 (xfrm, one of the eight) lists fixes only in 7.x releases, none for any 5.x or 6.x LTS branch.

Microsoft said the showcased root exploit, CVE-2026-64563, a flaw in a shared kernel hash-table library reached through socket diagnostics, works "without requiring special kernel configurations or user namespaces" and is "reachable by unprivileged users on standard kernels." So restricting user namespaces would not have stopped it. The CVE-2026-74544 record, by contrast, says unprivileged users reach it via user and network namespaces.

What to do now

We would act in this order:

1. Infrastructure, this week: compare uname -r on each host, not the installed package, with your vendor's tracker for the CVEs in Microsoft's post. Ask your vendor about CVE-2026-98364 (xfrm) even without IPsec; distribution kernels usually build xfrm in. Our Nov. 6 piece on OpenAI's kernel exploits makes the reboot-cycle argument.
2. SOC, this month: alert on a non-root process that becomes root and on unexpected module loads on servers.
3. Platform, this month: stop loading protocol modules you do not use, starting with the GTP tunnel driver (gtp) for mobile core networks, home to one of the eight bugs. Per modprobe.d(5), blacklist only makes modprobe ignore a module's internal aliases; install <module> /bin/false runs instead of inserting it. Where hosts do not need user namespaces, set user.max_user_namespaces to 0 (it breaks rootless containers and other tools that create user namespaces) and run containers under the runtime's default seccomp profile (Kubernetes leaves it off unless configured). Treat all of this as partial cover.
4. Capacity planning, next quarter: Microsoft said it scanned only a small fraction of the kernel, so budget reboot capacity for more reports.

Hosts where only admins run code and module loading is locked down gain little from this beyond normal patching.