Microsoft MDASH Linux kernel research turned 26,502 raw scan findings into 59 public upstream bug reports. Microsoft FORGE Lab reports 33 assigned CVEs, while fixes for 38 reports have reached the mainline kernel.
The striking result is the gap between finding possible bugs and getting verified fixes upstream. Microsoft says two weeks of scanning led to months of researcher review, maintainer discussion, and patch revisions.
Microsoft MDASH Linux Kernel Research: The Funnel in Four Numbers
FORGE Lab scanned selected networking, filesystem, and security components from late May to mid-June 2026. It chose security-sensitive code that could be validated in a consistent virtual-machine environment, according to its research report.
The system produced 26,502 raw findings on two servers in roughly two weeks. Confidence filtering and separate screening agents narrowed these to 11,769 candidates. Automated reproduction attempts then left 621 cases with proof-of-concept evidence for human review.
- 26,502raw scan findingsSource: Microsoft FORGE Lab, 11 November 2026
- 11,769screened candidatesSource: Microsoft FORGE Lab, 11 November 2026
- 621cases with laboratory reproduction evidenceSource: Microsoft FORGE Lab, 11 November 2026
- 59public upstream reportsSource: Microsoft FORGE Lab, 11 November 2026
Those stages measure different things. A raw finding is a lead, a reproduced case has supporting evidence, and an upstream report describes a distinct issue worth submitting. Microsoft says experts reviewed the 621 cases for root causes, duplication, and security impact.
Why Did Most Reproduced Cases Avoid a Separate Report?
Microsoft says 266 of the 621 cases shared a root cause with another case. One fix could address related manifestations, so counting each as a new vulnerability would exaggerate the number of distinct defects.
Another 163 were not reported after review, mostly because their security impact was limited. The team says 133 had already been reported or fixed upstream. The remaining 59 became its public upstream reports.
That distribution explains why a proof-of-concept-backed count should not be presented as a new-CVE count. It also shows the value of expert triage: duplicate detection and impact assessment change the size of the actionable queue.
Timing contributed to overlap. Microsoft says its first public report appeared on June 27, more than five weeks after scanning began. By September 1, 55 of the 59 reports were public; four later moved from private to public lists by mid-October.
What Did the Eight Local Root Tests Establish?
Microsoft says 33 CVEs have been assigned from this research, with 24 rated High or above under CVSS v3.1. Its team confirmed local root privilege escalation for eight CVEs in controlled laboratory conditions.
Some of those demonstrations required non-default settings or disabled mitigations, Microsoft cautions. A controlled local demonstration establishes technical impact under stated conditions. It does not establish that any of the eight bugs is being exploited in the wild.
The eight examples span networking, key handling, and a shared hash-table library. Microsoft highlights CVE-2026-64563 because a small state-reset error could leave a kernel iterator holding a stale pointer after a table resize.
The affected library is used by multiple kernel callers. Microsoft says the flaw became reachable through a caller available to unprivileged users on standard kernels. It also reports impact on Android with SELinux enforcing.
This example illustrates a defensive problem beyond one module. A defect in shared kernel code can have different consequences depending on the caller and the pause-and-resume behavior around it. Our reading is that component-level inventories alone can miss that reachability.
Why Is a Mainline Fix Not the End of the Work?
Microsoft says fixes for 38 reports have been merged into the upstream mainline. Half were accepted on the first submission. The other half needed one to four revisions during maintainer review.
From the first public patch to a mainline release, Microsoft reports a median of 41 days and a maximum of 108 days. It says work with maintainers continues on the remaining reports. These are project-level figures, not patch dates for every distribution.
A Linux operator needs a second mapping after an upstream merge: which supported distribution or device build contains the fix. Mainline status alone does not prove that a particular fleet image has received it. This is our operational inference from the upstream workflow.
Microsoft estimates that the 59 reported bugs had existed for 8.1 years on average before public reporting. It says one defect, CVE-2026-74544, had existed for at least 21 years. Age is a reason to inspect long-lived branches, not evidence of past exploitation.
The team says reporting 59 issues took more than four person-months, despite the short scanning phase. The research therefore points to a verification and remediation capacity constraint. More findings would increase the review queue unless triage and patch delivery also scale.
How Should Defenders Turn These Numbers Into a Work Queue?
Start by listing supported kernel builds across servers, containers’ host kernels, appliances, and Android devices where applicable. Compare each build with its vendor’s security notice and fixed package, because upstream commit timing differs from downstream delivery.
Use the eight laboratory-tested CVEs as a focused review set, then assess local access paths and configuration conditions for each. Microsoft says several tests needed unusual settings or weaker mitigations. That makes a single blanket exposure statement inaccurate.
Track patch state separately from research state. An assigned CVE, a public report, a merged upstream fix, and an installed vendor update represent different milestones. A useful vulnerability management workflow records all four.
For systems awaiting vendor fixes, review who can obtain local access and keep kernel exploit mitigations enabled. Preserve host telemetry and investigate suspicious privilege changes through the existing incident response plan. These are our defensive recommendations, not steps Microsoft claims will eliminate every risk.
After updates, verify the running kernel and any required reboot rather than relying on package installation alone. Record exceptions against the vendor’s published fixed build. The patch management guide provides a way to keep that evidence tied to each asset.
What Does Brandefense Blackhole Add to This Risk Picture?
The dispatcher-provided Brandefense Blackhole summary records 14,963 dark-chat references in a broad Microsoft query from August 13 through November 11, 2026. That query is not specific to MDASH, Linux, or these CVEs.
We therefore treat the count only as broad background attention around Microsoft. It cannot establish discussion of these kernel findings or successful exploitation. Risk decisions for this story should rest on affected builds, local access, and vendor fix status.
Method and Limits
This analysis uses Microsoft’s November 11 research account for the scan funnel, CVE tally, laboratory demonstrations, and upstream progress. Its counts describe a selected subset of kernel subsystems, not a census of the Linux kernel.
We grouped the 621 reviewed cases using Microsoft’s published categories and kept laboratory results separate from field exploitation. The article gives fleet-level triage guidance; operators should use their kernel vendors’ advisories for build-specific remediation.
Frequently Asked Questions
Did Microsoft confirm active exploitation of the eight CVEs?
Microsoft described controlled local laboratory demonstrations. Those results do not establish exploitation in production environments.
How many MDASH findings became distinct upstream reports?
Microsoft reported 59 public upstream reports after reviewing 621 cases with reproduction evidence. Many cases shared a root cause or overlapped earlier upstream work.
Does a mainline merge mean my Linux fleet is patched?
A mainline merge is an upstream milestone. Check your distribution or device vendor advisory, install its fixed build, and verify the running kernel.
