Two Weeks of Scanning, Four Months of Triage: Microsoft MDASH Turned 59 Kernel Bugs Into 33 CVEs

On 11 November 2026, Microsoft’s FORGE Lab published a full accounting of an experiment the industry has been circling for two years: what happens when frontier models are pointed at the Linux kernel at scale. The codename MDASH effort scanned a subset of kernel subsystems — networking, filesystems, security modules, chosen for QEMU-testability — from late May to mid-June 2026 with a team of one full-time researcher and one intern. The yield so far: 59 public upstream reports, 33 assigned CVEs (24 rated High or above), eight confirmed local root privilege-escalation exploits in lab conditions, and 38 fixes merged into mainline. The headline is the scale. The actual lesson, stated plainly by the authors, is the bottleneck: two weeks of scanning produced the findings; more than four person-months turned 59 of them into reports — and five months later, fixes are still landing.

The funnel: 26,502 findings down to 59 reports

The post’s most useful contribution is the attrition math, published stage by stage. Two servers (64 cores/256GB and 32 cores/128GB) generated 26,502 raw scan findings in about two weeks, with code scanning dominated by Sonnet 4.6 (71.1% of scanning tokens) alongside GPT-5.4 and GPT-5.5. Confidence filtering plus purpose-built screening agents cut that to 11,769 candidates; PoC-generating agents attempting QEMU reproduction — mostly GPT-5.5, with Opus 4.6 and GPT-5.5-cyber in support — produced 621 cases with exploit evidence; human experts then identified root causes, merged duplicates, and wrote upstream submissions for 59. Roughly one public report per ten PoC-backed cases. Of the cases that never became their own report, 266 shared a root cause with another case, 163 were judged limited security impact, and 133 were already reported or fixed upstream — the last category inflated by timing, since the first public report did not go out until 27 June, five-plus weeks after scanning finished, while others may have had parallel reports in flight. By 1 September, 55 of 59 were public; four went through private channels and reached the public lists by mid-October.

The fix half of the pipeline is where the romance of AI offense meets maintainer reality. Upstream Linux typically requires reports to arrive with a working patch; agents drafted initial fixes, but human validation, subsystem understanding, and review iteration remained essential. Half the merged fixes landed on first submission, the rest after one to four revisions, with a median 41 days from first public patch to mainline release and a tail out to 108 days. Discovery is parallelizable. Trust is not.

Old bugs, deep bugs: the 21-year-old and the rhashtable one-liner

The average reported bug was 8.1 years old at first public report; six were 15–19 years old and three were at least 20. The oldest, CVE-2026-74544, a cls_u32 shift-out-of-bounds flaw, had been present for at least 21 years (NVD lists it as Received, published mid-August). Eight CVEs got confirmed root exploits, spanning IPv6 fragmentation and IPsec routing use-after-frees (CVE-2026-64554, CVE-2026-64580, CVE-2026-98364), paired next-hop replacement races (CVE-2026-74561, CVE-2026-74562), a GTP tunnel-driver use-after-free (CVE-2026-89789), and an encrypted-key heap overflow through a 16-bit length (CVE-2026-98222) — with the caveat that some required non-default settings or disabled mitigations.

The post walks through CVE-2026-64563 in full, and it is worth following: a one-line state-reset bug in rhashtable, the kernel’s shared resizable hash table. A 2018 commit moved the iterator reset into the resume path but covered only one of two resume branches, so a paused-and-resumed walk across a table resize could follow a freed pointer. The exploitable caller, __netlink_diag_dump(), is reachable by unprivileged users who control the pause between dump replies — turning a stale pointer into a constrained 64-bit write and, paired with standard techniques, local privilege escalation, including on Android with SELinux enforcing. Microsoft credits Yuan Tan and Frank Wu of NebuSec for independent discovery and working exploits. Read alongside OpenAI’s priced kernel-offense pipeline covered here earlier this month, the shape is consistent: the kernel’s oldest shared infrastructure keeps paying out to whoever looks systematically.

What this means for defenders

Three takeaways survive contact with the numbers. First, the finding-to-fixing imbalance is the story: scanning covered only a small fraction of the kernel, and more tokens would find more bugs — but the authors’ own verdict is that more bugs do not equal a secure system, and both hunters and maintainers drown in real findings. Triage capacity, not scan capacity, is the scarce resource. Second, age is not safety: two-decade-old bugs in core subsystems mean legacy code assumptions deserve the same adversarial review as new attack surface, a point that rhymes with this month’s dormant-neuron backdoor research on how little needs to change for a large effect. Third, the bottleneck is economic and operational: the lab frames the work as informing how MDASH-class capabilities reach security teams, but the honest read is that AI has industrialized the cheapest stage (finding) while the expensive stages (validating, patching, landing fixes across 41-day medians) remain stubbornly human.

What to actually do

  1. Budget triage before you budget scanning. Any team deploying AI code-scanning should staff the PoC-validation and upstream-reporting tail first — the Microsoft ratio (26,502 findings to 59 reports) is what unmanaged output looks like without it.
  2. Prioritize ancient shared infrastructure. Hash tables, socket-diagnostic paths, and reference-counted routing code are where decades-old single-line bugs convert directly to privilege escalation. Put rhashtable-class library code and its pause/resume callers on your audit list.
  3. Track the eight root-LPE CVEs to patch state (64554, 64563, 64580, 74561, 74562, 89789, 98222, 98364) and the 21-year-old 74544: with 38 of 59 fixes merged and a 41-day median to mainline, downstream kernels trail by months — verify your fleet’s kernel actually contains the fixes rather than assuming the CVE entry means coverage.
  4. Treat AI-found vulnerability volume as a maintainer-load problem: if your project accepts automated reports, define acceptance bars (working PoC, proposed patch, deduplication against in-flight reports) before the flood arrives, or the 133 already-reported overlaps in this study become your inbox.

Our verification was read-only. We read the Microsoft Security Blog post first-hand in full (FORGE Lab, Cen Zhang, 11 November 2026: MDASH scan late May to mid-June 2026, one researcher plus one intern, three-month effort; 26,502 raw findings, 11,769 screened, 621 PoC-backed, 59 upstream reports, 33 CVEs with 24 High or above, eight lab-confirmed root exploits, 38 mainline fixes; Sonnet 4.6/GPT-5.4/GPT-5.5 scanning split and GPT-5.5/Opus 4.6/GPT-5.5-cyber reproduction split; 266 duplicate-root-cause, 163 limited-impact, 133 already-reported dispositions; 27 June first public report, 55 of 59 public by 1 September; 8.1-year average bug age, CVE-2026-74544 at 21-plus years, six at 15–19 years, three at 20-plus; eight-CVE root-LPE table; CVE-2026-64563 rhashtable deep-dive with 2018 commit 5d240a8936f6, __netlink_diag_dump unprivileged reachability, Android SELinux-enforcing impact, NebuSec credit; 41-day median and 108-day max to mainline). Both headline CVEs were confirmed present in NVD first-hand (74544 Received, 64563 Undergoing Analysis). We ran no scanner, reproduced no PoC, and contacted no vendor. Brave Search was used for discovery only.

Sources: