Microsoft MDASH Found 59 Linux Kernel Bugs: 33 CVEs and Eight Root Exploits

Microsoft's FORGE Lab says an AI scanning system called MDASH helped it file 59 public Linux kernel bug reports, which produced 33 CVEs, 38 merged mainline fixes and working local root exploits for eight of the CVEs. The write-up, "Lessons from 59 Linux Kernel Bug Reports", was published on November 11, 2026. The oldest bug had been in the kernel for at least 21 years.

For anyone running coding agents on Linux, the practical message is the same as in recent weeks: a local, unprivileged foothold on an unpatched kernel should be treated as one step from root. This is a vendor research report, not a disclosed attack campaign, and it describes lab exploits. Below is what the pipeline did, how the one fully described exploit works, and what to change on agent hosts.

TL;DR

What did Microsoft's MDASH pipeline do?

MDASH is an internal Microsoft system used by FORGE Lab. A team of one full-time researcher and one intern ran the effort over about three months. They picked security-sensitive subsystems such as networking, filesystems and security modules, and avoided components that depend on specialised hardware so that every candidate could be tested the same way in QEMU virtual machines.

Microsoft describes four stages:

1. Scanning. MDASH produced 26,502 raw findings in about two weeks on two servers. By token share, code scanning used Sonnet 4.6 (71.1%), GPT-5.4 (20.1%) and GPT-5.5 (7.1%).
2. Screening. MDASH confidence levels and separate fast-screening agents cut the pool to 11,769 candidates.
3. Reproduction. Proof-of-concept agents tried to reproduce each candidate in QEMU, mainly with GPT-5.5 (77.3% of tokens), Opus 4.6 (13.2%) and GPT-5.5-cyber (9.4%). That left 621 cases with proof-of-concept evidence.
4. Expert review. Humans identified root causes, merged duplicates and prepared upstream submissions. That produced the 59 reports, about 9.5% of the PoC-backed cases.

The attrition is the interesting part. Of the 621 PoC-backed cases, 266 (42.8%) shared a root cause with another case, 163 (26.2%) were not reported because of limited security impact, and 133 (21.4%) had already been reported or fixed upstream. In other words, most machine-found "bugs" are duplicates, low impact or already known, which is why human validation was the slow part of the effort.

What came out of it?

According to Microsoft, 33 CVEs have been assigned so far and 24 are rated High or above (CVSS v3.1 of 7.0 or more). The average bug was 8.1 years old when first reported. The oldest, a cls_u32 shift-out-of-bounds bug (CVE-2026-74544), had been present for at least 21 years. Fixes for 38 reports have been merged into mainline, and about half were accepted on the first submission; the rest needed one to four revisions. The median time from first public patch to a mainline release was 41 days, with a maximum of 108. The first public report went out on June 27, more than five weeks after scanning began.

Microsoft confirmed working local root privilege-escalation exploits for eight of the CVEs, tested in lab settings. Some needed non-default settings or disabled protections, and most are use-after-free bugs. A secondary news summary from Cyber Security News lists eight CVEs in networking, key management and a tunnel driver, including:

Check each id against your distribution's tracker rather than relying on this list.

How does the rhashtable exploit work?

Microsoft walks through CVE-2026-64563, a one-line use-after-free in rhashtable, the kernel's shared resizable hash table library. The root cause traces to a 2018 commit that kept the iterator's saved pointer (iter->p) across walk stops and moved the reset into rhashtable_walk_start_check(). That reset was missed on the path where a resize has freed the old bucket table, so a stale pointer survived. When the walk resumed, rhashtable_walk_next() followed a pointer to possibly freed memory.

Three events must coincide in a single walk: the iterator is paused and resumed, a resize frees the old table during the pause, and the entry at iter->p is removed and freed. That narrow window explains why the bug went unnoticed for about eight years.

Of roughly two dozen rhashtable walker users, the authors identified __netlink_diag_dump() as exploitable. Unprivileged users can reach it on standard kernels, and user space controls the pause between replies through recvmsg(). The chain Microsoft describes:

1. Start a Netlink socket diagnostics dump and pause it between replies.
2. Trigger a resize of the table while the dump is paused.
3. Free the socket that iter->p points to, then reallocate that memory so the freed entry's next pointer references attacker-controlled data.
4. Resume the dump. The kernel treats a fake socket as real, and sock_diag_save_cookie() yields a constrained 64-bit write.
5. Combine that write with other techniques to reach local privilege escalation.

Microsoft says it works without special kernel configuration or user namespaces, and that it also affected Android with SELinux enforcing. The upstream fix simply clears iter->p before returning. Credit for an independent find, and for Linux and Android exploits, goes to Yuan Tan and Frank Wu of NebuSec.

What are the lessons Microsoft draws?

The authors' main point is that discovery is no longer the hard part. Scanning took two weeks, but reporting 59 bugs took more than four person-months, and merging fixes took months more. Agents helped draft initial patches, but human validation, subsystem knowledge and maintainer iteration stayed essential. They also prioritised high-severity issues to avoid flooding maintainers, and they question whether fixing every bug would make a system secure, since the scan covered only a small slice of the kernel.

This fits a pattern we have covered: OpenAI's 948 Linux root exploits and Anthropic's AI-built exploit chains for Chrome, Linux MPTCP and Windows QUIC. Three labs, three pipelines, the same direction: more kernel bugs found per month, with older bugs surfacing.

What this means if you run AI coding agents

An agent is a low-privileged account that executes commands you did not write. Prompt injection, a malicious skill or a poisoned dependency can give an attacker exactly the local foothold these exploits need. These steps come from standard Linux practice and the report's findings, not from any new official guidance; Microsoft's post has no formal recommendations section.

• Update the kernel and reboot. Install your distribution's newest kernel and actually restart. Check uname -r before and after, and read your vendor's security tracker for the CVE ids above.
• Prioritise the eight exploited CVEs. Netlink diagnostics, IPv4/IPv6 routing, IPsec (xfrm) and the GTP driver are the areas named. Servers and CI runners that expose those paths deserve the first reboot window.
• Turn on automatic security updates on laptops, CI runners and self-hosted agent boxes, and expect a steady stream of kernel advisories as AI-assisted scanning continues.
• Isolate agents. Run them in a VM or microVM rather than directly on a host with valuable credentials. See Capsem, a VM sandbox for coding agents and Google's no-credentials microVM design.
• Keep secrets away from the agent user. If the agent cannot read long-lived tokens, a local root exploit has less to take on its first hop. Rotate anything an agent session could have exposed.
• Reduce kernel attack surface where practical. Disabling unneeded kernel features and services shrinks the reachable code; restricting unprivileged access to socket diagnostics is our inference from the exploit path, not Microsoft's advice, and may break monitoring tools.
• Check logs after agent sessions for unexpected sudo, new setuid files, new users or cron entries.

What Beam can and cannot do here

Beam cannot stop a kernel exploit. It is not a kernel sandbox, and once code is running locally with a working privilege escalation, hook-based controls can be bypassed. What it can do is act earlier in the chain. For Claude Code and Codex, Beam's PreToolUse hooks can flag and, under workspace enforce policy, deny risky commands such as credential reads and privilege-escalation attempts before they run. It keeps an on-device record of what the agent did, with secrets redacted before storage, and its skill and MCP scanner checks for risky patterns with heuristics rather than semantic analysis. See what Beam watches and how it works. Use it as one layer next to patched kernels and VM isolation.

What are the limits of this report?

It is Microsoft's own account. We did not reproduce any exploit, and we have only the vendor blog and a secondary news summary. Microsoft says some exploits needed non-default settings or disabled protections, and does not publish the exploits. The post does not say which distributions ship which fixes, so we cannot give per-distribution patched versions. Counts will shift as more CVEs are assigned and fixes land.

Frequently asked questions

What did Microsoft report about the Linux kernel?

Microsoft's FORGE Lab says its MDASH system scanned selected Linux kernel subsystems from late May to mid-June 2026 and led to 59 public upstream reports, 33 assigned CVEs, 38 fixes merged into mainline and working local root exploits for eight CVEs. Twenty-four of the 33 CVEs are rated High or above.

Can these kernel bugs be exploited remotely?

The exploit described in detail, CVE-2026-64563, is a local privilege escalation: an attacker needs to already run code as an unprivileged user. Microsoft says it works on standard kernels without user namespaces. Some of the other eight exploits needed non-default settings or disabled protections.

How do I know if my kernel has the fixes?

Run uname -r, then check your distribution's kernel security advisories for the CVE ids in Microsoft's post, such as CVE-2026-64563, and install the latest kernel package and reboot. Fixes for 38 reports were merged into mainline, but distributions ship them on their own schedule.

Why does this matter for AI coding agents?

A coding agent runs commands as a local user. If a prompt injection, malicious skill or poisoned dependency makes it run attacker code, an unpatched kernel turns that foothold into root. Patching kernels and isolating agents in a VM limits the damage.

Can Beam block a kernel exploit?

No. Beam is hook-based monitoring and deny for agent actions, not a kernel sandbox. For Claude Code and Codex it can flag and deny risky commands before they run and keeps an on-device record, but it cannot contain an exploit once code runs locally.

Does AI finding bugs mean the kernel is less secure?

Not by itself. Microsoft argues the bottleneck is human validation and upstream acceptance, not discovery, and that fixing every bug does not make a system secure. The practical effect is more reports and CVEs per release, so patch pipelines need to keep up.

Related reading

• OpenAI's 948 Linux root exploits and what to patch
• Anthropic's AI-built exploit chains: Chrome 156, Linux MPTCP and Windows QUIC
• Capsem: a VM sandbox for AI coding agents
• GSocket Linux backdoor persistence after app patches
• Linux KSMBD flaws posted before a fix
• Source: Microsoft Security Blog, "Lessons from 59 Linux Kernel Bug Reports" (November 11, 2026)

Figures and status are accurate as of November 12, 2026, based on Microsoft's published report. Patch status will change as distributions release fixes; check your vendor's advisories.