Microsoft's FORGE Lab says 26,502 raw Linux kernel findings became 59 reports, 33 CVEs, 8 root exploits
Microsoft's FORGE Lab says its MDASH scans of Linux kernel code produced 26,502 raw findings, from which came 59 upstream reports, 33 CVEs, eight confirmed local root exploits and 38 merged fixes. The post says human effort, not scanning, was the bottleneck.
By Parminder Kumar Sharma · LinkedIn · · 22 min read
59 reports from 26,502 raw findings is 0.22 per cent (derived)
Microsoft's FORGE Lab says that scans of Linux kernel subsystems, run with a tool it calls MDASH, produced 26,502 raw findings in about two weeks. Its post, published on 11 November 2026, says the work has so far produced 59 public upstream reports, 33 assigned CVEs and fixes for 38 of the reports merged into mainline, and that the lab confirmed working root privilege escalation exploits for eight of the CVEs. 59 of 26,502 is 0.22 per cent (derived). This site read the lab's two copies of the post, the lab's CVE list and the CVE.org records between 21:39 and 21:55 UTC on Wednesday 11 November 2026.
That ratio is not a hit rate, and it is not an error rate. The post calls the 26,502 "raw" findings: they were scanner output, not 26,502 claimed bugs. It does not say how many were false positives, how many repeated known issues, what the scans cost in dollars, or how many hours kernel maintainers spent on the reports. What it does print is more than most AI bug counts come with: a stage by stage funnel, the tokens spent at each stage, the models named, and the human time. This article sets those figures out, checks the 33 CVE ids against CVE.org, and keeps what is missing visible.
The flaws are not new. CVE.org lists all 33 ids as published, with publication dates from 27 July to 28 October 2026 (derived from the records), so the fixes and advisories came months before this retrospective. The post is a look back at how the lab got from thousands of findings to a few dozen fixed bugs.
The funnel, stage by stage
The post and its Figure 1 give a count at each stage and say what happened between them. The lab names its effort as led by "one full-time researcher and one intern"; no individual is named here. The validation environment is QEMU: the lab says it chose components with "no obvious dependence on specialized hardware", which made that validation "simple and unified".
The funnel as the lab's post and Figure 1 print it. Counts are the lab's; the last column adds what this site derived.
| Stage | What the post says happened | Count, and derived ratio |
|---|---|---|
| Scan | MDASH scans of a subset of kernel subsystems, late May to mid-June 2026, about two weeks, on two servers (64 cores and 256 GB RAM; 32 cores and 128 GB RAM). | 26,502 raw findings |
| Screen | Low-confidence claims filtered out using MDASH's confidence levels and separate fast screening agents the lab built. | 11,769 candidates: 44.4% of raw; 14,733 removed (derived) |
| Reproduce | Proof of concept generating agents tried reproduction in QEMU. Experts then reviewed the cases with evidence for root causes, duplicates and upstream submissions. | 621 cases: 5.3% of candidates (derived) |
| Report | First public report 27 June 2026; 55 of 59 public by 1 September; four reported privately and routed to the public lists by mid-October. | 59 reports: 9.5% of 621 (the post); 0.22% of raw (derived) |
| Fix | Fixes for 38 reports merged into mainline: half on the first submission, the rest after one to four revisions. Median 41 days from first public patch to a mainline release, up to 108. | 38 of 59 (64.4%, derived) |
| CVE and exploit | 33 CVEs assigned so far; local root exploits confirmed in laboratory environments for eight of them. | 33 CVEs; 8 exploits (24.2% of the 33, derived) |
Two details sit only in the lab's own blog copy of the figure. Its description says 10,842 of the 11,769 screened candidates "entered proving", so 927 candidates did not (derived), and the post's text never mentions 10,842 or says why 927 were not run. The same description calls the screening stage "confidence validation and Linux-aware filtering". Neither post says how many of the 11,148 candidates that did not reach the 621 (derived) failed because they were wrong and how many because the agents could not build a working proof of concept.
Who and what did the work
The post names its models and gives each one's share of the tokens at two stages. It does not name the models' makers. The names Sonnet and Opus are Anthropic's, and GPT-5.4, GPT-5.5 and GPT-5.5-cyber are OpenAI's; the post attributes nothing to either company beyond the model names. MDASH itself is only described as a codename for the scanning tool, with confidence levels and agents; the post does not say what it adds to the models.
Models and token shares as the lab's post prints them, with the figure's differences marked. Sums are derived.
| Stage | Post text | Figure 1 |
|---|---|---|
| Code scanning | Sonnet 4.6 71.1%, GPT-5.4 20.1%, GPT-5.5 7.1% of code-scanning tokens (sum 98.3%, so 1.7% is not attributed, derived) | 33.25B tokens. Sonnet 4.6; GPT-5.4 / GPT-5.5; Opus 4.6 / 4.8 |
| Static screening | Confidence levels and fast screening agents; no model named | 5.60B tokens. GPT-5.4 / GPT-5.5; GPT-5.5-cyber; Opus 4.6 / 4.8 |
| Reproduction in QEMU | GPT-5.5 77.3%, Opus 4.6 13.2%, GPT-5.5-cyber 9.4% of reproduction tokens (sum 99.9%, derived) | 42.68B tokens. GPT-5.5; Opus 4.6; GPT-5.5-cyber |
| Human effort | One full-time researcher and one intern; "over four person-months" to report 59 | 2+ months, 1 FTE + 1 intern, review and patching |
The three token totals add to 81.53 billion (derived), which the figure's description calls "rounded pipeline token totals". That is about 1.38 billion tokens per upstream report (derived). No price per token is printed, so no dollar cost can be derived, and none is stated. The post's prose lists Opus 4.6 only for reproduction, while the figure lists "Opus 4.6 / 4.8" against scanning and screening too; the post does not reconcile them, and this article does not guess.
On people, the opening says one full-time researcher and one intern led "this three-month effort", the figure puts review and patching at 2+ months within "an overall effort of about three months", and the closing says it took "over four person-months" to report 59 cases. Fewer than 15 reports per person-month follows (derived, 59 divided by more than 4). Maintainers' time is not counted anywhere in the post, although the post says maintainers and bug hunters "can be overwhelmed by the volume of real findings".
Selling interest, stated once. Microsoft sells security products. Its blog files the post under Microsoft Defender, and the post closes by saying the goal is to bring advances in AI powered security research "into the hands of security teams". The post announces no product and prices nothing.
Where the 621 cases went
Here the post is unusually exact. Of the 621 cases that had proof of concept evidence, 59 became public upstream reports. It gives the reasons for the rest, and the four numbers add up to 621 (derived).
The 621 cases with proof of concept evidence, as the post counts them. Shares are the post's; the sum check is derived.
| Outcome | Cases | Share of 621 |
|---|---|---|
| Became an upstream report | 59 | 9.5% |
| Shared a root cause with another case (one patch can fix them together) | 266 | 42.8% |
| Not reported after review, mostly due to limited security impact | 163 | 26.2% |
| Already reported or fixed upstream | 133 | 21.4% |
| Sum of the four rows (derived) | 621 | 100% |
These counts answer part of the duplicates and rejection question, but only at the 621 level. The post says submission timing explains many of the 133 overlaps: most cases "were new when the scans finished (though some may already have been in flight by others)", and the first public report went out on 27 June 2026, "more than five weeks after scanning started". It does not say how many of the 26,502 raw findings or the 11,769 candidates were duplicates, known issues or simply wrong. A report that is merged, merged late or refused is also a different outcome from a report that is made: the post counts 38 merges and says the lab is "still working with maintainers on the remaining reports", which is 21 reports (derived) with no status given.
After the report: fixes, and how old the bugs were
The post explains why the human stage is slow: upstream Linux typically wants a working patch with a report. "Agents helped draft initial fixes", it says, but human validation, subsystem understanding and iteration with maintainers "remained essential". Fixes for 38 reports are merged: half on the first submission, the rest after one to four revisions, with a median of 41 days from the first public patch to a mainline release and a longest of 108.
The bugs are old. Across the 59 reports the average bug was 8.1 years old when first reported publicly, measured from the commit that introduced it to the lab's first public report. The oldest named, a flaw in the cls_u32 traffic classifier (CVE-2026-74544), had been present for at least 21 years. The lab's own blog copy of the age figure also prints a median of 5.6 years and the bin counts below; the post's text does not.
Age of the 59 reported bugs at first public report, as the lab's age figure prints it (the lab's blog copy). The sum is derived.
| Age at first public report | Reports |
|---|---|
| Under 1 year | 2 |
| 1 to under 3 years | 6 |
| 3 to under 5 years | 15 |
| 5 to under 10 years | 22 |
| 10 to under 15 years | 5 |
| 15 to under 20 years | 6 |
| 20 years or more | 3 |
| Sum (derived) | 59 |
The 33 CVE ids: the file, the post and CVE.org
The lab's file cves.txt, as GitHub shows it, is 495 bytes: 33 lines, one CVE id per line, in ascending order (derived), with 33 distinct ids (derived count). That matches the post's "33 assigned CVEs". The post names only nine of the 33 in its text: the eight in its root exploit table and CVE-2026-74544 for the old cls_u32 bug. The other 24 ids appear only in the file (derived). The file prints no subsystem, score or description.
The CVE.org records fill the gap. Each record's list of changed files puts 24 of the 33 under net/ (ipv4 6, ipv6 3, xfrm 3, tipc 2, netfilter 2, xdp 2 and one each in rds, sctp, sched, openvswitch, core and mac80211), 4 in drivers/net, 2 in fs/smb (the ksmbd server), and one each in lib, security/keys and the core reboot code (derived from the first file each record lists). That agrees with the post's "networking, filesystems, and security modules" as examples, and shows two more areas, lib and the reboot code, that the post's three words do not cover.
Severity differs by a count of one. The post says 24 of the 33 are rated High or above, meaning a CVSS v3.1 score of at least 7.0, and does not say who scored them. At the time of reading, the CVE.org records for 23 of the 33 carry a CVSS v3.1 score from the Linux kernel CNA, all 7.0 or more (22 High and one Critical), and the other 10 records carry no score. 24 versus 23 is not explained by any page read, and this article does not resolve it. Of the 23 scores, 17 have a local attack vector, 5 a network vector and 1 an adjacent vector (derived). The one Critical is CVE-2026-89788, scored 9.8 with a network vector, in the ksmbd server's tree connect handling. It is not among the eight exploits the post tabulates, and the post does not mention it.
The eight CVEs the post tabulates as local root exploits: the module as the post prints it, and the score as the CVE.org record gives it (Linux kernel CNA, read at the time stated).
| CVE id | Module (post) | Score in the CVE.org record |
|---|---|---|
| CVE-2026-64554 | net/ipv6 | 8.8, High |
| CVE-2026-64563 | lib/rhashtable | 7.8, High |
| CVE-2026-64580 | net/ipv6 | 7.8, High |
| CVE-2026-74561 | net/ipv4 | 8.8, High |
| CVE-2026-74562 | net/ipv4 | 8.8, High |
| CVE-2026-89789 | drivers/net | 7.8, High |
| CVE-2026-98222 | security/keys | no score in the record |
| CVE-2026-98364 | net/xfrm | 7.8, High |
Seven of the eight carry a High score in their records, 7.8 to 8.8; CVE-2026-98222 (security/keys) carries none. The attack vectors of those seven are local, apart from CVE-2026-64554, which is scored with an adjacent vector (derived). No record among the 33 has a credits field naming a finder, and one record, CVE-2026-74561, names Microsoft in its scoring rationale. The CISA Known Exploited Vulnerabilities catalogue released on 10 November 2026 (1,779 entries) lists none of the 33. Absence from that catalogue is not evidence that nothing has been exploited, and the post does not say either way.
What "confirmed working" means, as the post words it
The post defines the eight exploits in one sentence: they are CVEs "for which we confirmed local root privilege-escalation exploits in controlled laboratory environments, with some cases requiring non-default settings or disabled exploit mitigations". That is the whole definition. It does not say which cases needed non-default settings, which mitigations were off, which kernel versions or distributions were used, or how many attempts failed.
One case gets a deeper write-up. For CVE-2026-64563, a one-line state reset bug in the kernel's shared resizable hash table, the post says the flaw enabled a "stable local privilege escalation" on Linux, and affected Android with SELinux enforcing, "without requiring special kernel configurations or user namespaces". No such sentence is printed for the other seven, and this article draws no conclusion from that.
The post also credits an outside security firm, NebuSec, with independently finding that flaw, with sharing its real severity with the lab and the maintainers, and with later providing its own working exploits for Linux and Android. A second person at the same firm is credited with a viable exploitation primitive and a working exploit. So for at least this one of the eight, working exploits are credited to people outside the lab. For all eight the post says "we confirmed"; it does not say whether the exploits for the other seven were written in the lab, whether any were shared outside it, or whether anyone else has replicated them. The post then describes the exploitable path in detail; this article does not repeat it.
Where the two copies of the post differ
Microsoft's Security Blog and the FORGE Lab's own blog carry the same post. A line by line comparison of the texts (derived) finds identical wording apart from link markup and the order of two bullets in the rhashtable section. The differences are in what surrounds the text.
The Microsoft Security Blog copy and the FORGE Lab blog copy, compared by this site between 21:39 and 21:55 UTC on Wednesday 11 November 2026.
| Item | Microsoft Security Blog | FORGE Lab blog |
|---|---|---|
| Byline | The lab and one named author | One named author |
| Published | 2026-11-11 at 16:55 UTC; modified 17:54 UTC (page data) | 11 November 2026 (date only) |
| Read time printed | 7 min | 9 min |
| Figure 1 | Raster image with a text caption naming the four counts | SVG whose description adds the 10,842 that entered proving and the token totals in words |
| Figure 2 | Raster image with a caption giving the mean and the 15 to 19 and 20 plus counts | SVG that also prints the median of 5.6 years and all seven bin counts |
| Links | Many: kernel mailing list threads for each report, kernel source lines, commits, the lab's cves.txt | Fewer: CVE.org for each table row, one mailing list thread, a relative link to cves.txt |
| Product tag | Filed under Microsoft Defender | None read |
| Licence printed | Not read | CC BY 4.0 in the footer |
The token totals and the Opus 4.8 entry are in Figure 1 of both copies, but in neither copy's text. A reader of only the text, or of the listing summary, misses them. Microsoft's page records a modification an hour after publication; the copy read here was saved later that day, and whether any text changed in that hour is not known.
Beside OpenAI's Linux pipeline: different denominators
An earlier briefing on this site covered OpenAI's account of an AI pipeline that built Linux root exploits. The two reports are about different runs, and their stages are defined differently, so this table only sets out what each says, from OpenAI's post as saved on 5 November 2026 and from Microsoft's. It ranks neither.
What each organisation reports about Linux kernel work with AI. Ratios are derived by this site and use each report's own stage definitions.
| Item | Microsoft FORGE Lab, 11 Nov 2026 | OpenAI, 4 Nov 2026 |
|---|---|---|
| Run | Scans late May to mid-June 2026; reports and fixes over the following months | One run in mid-October 2026; scan and manual analysis finished after 10 days |
| First count | 26,502 raw scan findings | 2,308 candidate findings after deduplication |
| Reproduced | 621 cases with proof of concept evidence (of 11,769 candidates) | 1,724 vulnerabilities reproduced within 30 hours |
| Root exploits | 8 confirmed, for CVEs, in laboratory environments | 948 local privilege escalation exploits |
| Exploits as a share of the stage before | 8 of 621 is 1.3% (derived) | 948 of 1,724 is 55.0% (derived) |
| Exploits as a share of the first count | 8 of 26,502 is 0.03% (derived) | 948 of 2,308 is 41.1% (derived) |
| Cost stated | 81.53 billion tokens in total (derived sum); no dollars | $1,213,430 in API credits |
| Human effort stated | One full-time researcher and one intern, over four person-months to report 59 | Human researchers reviewed outputs; no person-hours stated in the text read |
The denominators differ in three ways: OpenAI's first count is after deduplication while Microsoft's is raw scanner output; Microsoft counts exploits against CVEs and OpenAI counts them against vulnerabilities it reproduced; and the two targeted different slices of kernel code. A ratio taken across the two columns would compare unlike units.
What the posts state, and what they do not
Stated and not stated in the two copies of the post, between 21:39 and 21:55 UTC on Wednesday 11 November 2026. The right column is this site's list of gaps.
| Item | Stated | Not stated |
|---|---|---|
| False positives | Low-confidence claims filtered; 163 of 621 proof of concept cases not reported, mostly for limited security impact | A false positive rate; how many of the 26,502 were wrong |
| Duplicates | 266 shared a root cause and 133 were already reported or fixed, both out of 621 | Duplicates or known issues among the 26,502 or the 11,769 |
| Rejections and maintainer effort | 38 merged; half on first submission; median 41 days; still working on the rest | Rejected reports; maintainer hours; status of the other 21 reports (derived) |
| Compute | Two servers; 81.53 billion tokens in total (derived sum) from Figure 1 | A dollar cost; the price or terms of any model |
| Which model did what | Token shares for named models at scanning and reproduction | The model behind the screening agents in the text; what MDASH adds; 1.7% of scanning tokens |
| Severity | 24 of 33 High or above on CVSS v3.1 | Who scored them; which 24; why the records show 23 (derived) |
| Exploitation | Eight root exploits confirmed in laboratory environments, some with non-default settings or mitigations off | Exploitation in the wild (none stated); which cases needed what; whether the other seven exploits were written in the lab (the post says "we confirmed"); sharing outside the lab; replication |
| Unfixed bugs | Still working with maintainers on the remaining reports | A list or count of unfixed CVEs; how reports map to the 33 CVEs (59 minus 33 is 26, derived, but one CVE may cover several reports) |
| Scope | "A small fraction of the kernel"; networking, filesystems, security modules as examples | The share scanned as a figure; the full subsystem list |
The post's own conclusions are worth keeping separate from its counts. It says "Finding bugs and fixing them are drastically out of balance", that "More tokens may yield more bugs, but not a secure system", and that the more urgent problem is building security solutions that are "operational, cumulative, and economically sensible". Those are the lab's opinions, offered with a figure set it chose to publish.
What to do, in order
The post prints no checklist for readers. Its own conclusions are that humans stay in the loop, that effort should go to genuinely high severity issues, and that discovery is only one part of the work. The actions below are this site's suggestions, drawn from the counts above.
Take this with you
This site's suggestions, in order
- Ask any vendor quoting an AI found bug count for the funnel in the same units: raw, triaged, reproduced, reported, fixed, with the human time spent at each stage.
- Treat raw findings as leads. In this report 9.5 per cent of proof of concept backed cases became reports, and the raw to report ratio was 0.22 per cent (derived).
- Budget triage and maintainer capacity before a scan, not after. The post says both bug hunters and maintainers can be overwhelmed by volume.
- Read each of the 33 CVE.org records against the kernel versions you actually run, including vendor, distribution and Android kernels, and track upstream fix status for each one that applies.
- Check which of the named areas are built or loaded on your hosts: networking features such as IPsec, tunnelling, SCTP, TIPC and nexthop routing, the ksmbd server, and kernel key handling. A module that is not present is not reachable.
- Put patches for local privilege escalation first on shared machines: build agents, container hosts, multi user servers and anything that runs untrusted local code.
- Check network facing items first within the list: five of the 23 scored records have a network vector, including the one rated Critical.
- Re-check the CISA catalogue and your vendors' advisories for exploitation reports, and do not read the absence of a listing on 10 November as safety.
Technical details
The posts print no exploit code, no steps, no network indicators and no hashes, and this section adds none. What they and the lab's file do print is below, copied as printed. Defenders can use the CVE list and the fix commit to check their own kernels; the working exploitation path in the post is deliberately not reproduced.
The lab's CVE list. This is the whole of cves.txt as the page showed it: 33 lines, one id per line. Use it as a checklist against your kernel vendors' advisories.
CVE-2026-64554
CVE-2026-64563
CVE-2026-64575
CVE-2026-64576
CVE-2026-64577
CVE-2026-64578
CVE-2026-64579
CVE-2026-64580
CVE-2026-64581
CVE-2026-68289
CVE-2026-68290
CVE-2026-68297
CVE-2026-68315
CVE-2026-74544
CVE-2026-74561
CVE-2026-74562
CVE-2026-74579
CVE-2026-74701
CVE-2026-74710
CVE-2026-74726
CVE-2026-74748
CVE-2026-89788
CVE-2026-89789
CVE-2026-89790
CVE-2026-90115
CVE-2026-97938
CVE-2026-98222
CVE-2026-98364
CVE-2026-98384
CVE-2026-98810
CVE-2026-98968
CVE-2026-99138
CVE-2026-99139
Names and counts as printed. The tool name, the models and the stage figures from the lab's Figure 1 (text taken from the SVG on the lab's blog), exactly as printed. The "derived" lines are this site's sums, marked as such.
codename MDASH
26,502 | Raw scan findings
11,769 | Candidates for proving
621 | Cases with PoC evidence
59 | Upstream reports
Scan pipeline | 33.25B tokens | Sonnet 4.6 | GPT-5.4 / GPT-5.5 | Opus 4.6 / 4.8
Static screening | 5.60B tokens | GPT-5.4 / GPT-5.5 | GPT-5.5-cyber | Opus 4.6 / 4.8
PoC pipeline | 42.68B tokens | GPT-5.5 | Opus 4.6 | GPT-5.5-cyber
Human effort | 2+ months | 1 FTE + 1 intern | Review + patching
(derived) 33.25 + 5.60 + 42.68 = 81.53 billion tokens
The one fix the post prints. For CVE-2026-64563 the post prints the restart path where the stale pointer was not cleared, and the one line the upstream fix adds. A defender uses it to recognise the fix in a kernel changelog: the 2018 commit named in the post introduced the behaviour, and the fix commit id is in the link the post attaches to the words "The upstream fix".
if (!iter->walker.tbl) {
iter->walker.tbl = rht_dereference_rcu(ht->tbl, ht);
iter->slot = 0;
iter->skip = 0;
return -EAGAIN;
}
+ iter->p = NULL;
2018 commit that moved the reset (named in the post): 5d240a8936f6
Upstream fix commit (from the post's link target): 8173f7e2ce67e6ca1d4763f3da14e5b01ce77456
The 33 records, read against CVE.org. The subject line is the commit subject as each CVE.org record prints it, and the score is the CVSS v3.1 base score in the record, given by the Linux kernel CNA at the time of reading (derived listing, no score where the record carries none). Use it to find the records that apply to the subsystems you run; the records' own affected and unaffected version ranges are the source for fixed versions, and are not repeated here.
The 33 ids from cves.txt with the commit subject and score as each CVE.org record printed them (the Linux kernel CNA, records read between 21:39 and 21:55 UTC on Wednesday 11 November 2026).
| CVE id | Commit subject in the record | Score |
|---|---|---|
| CVE-2026-64554 | netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() | 8.8 |
| CVE-2026-64563 | rhashtable: clear stale iter->p on table restart | 7.8 |
| CVE-2026-64575 | bpf: tcp: fix double sock release on batch realloc | 7.8 |
| CVE-2026-64576 | nexthop: initialize extack in nh_res_bucket_migrate() | 7.1 |
| CVE-2026-64577 | gtp: check skb_pull_data() return in gtp1u_send_echo_resp() | 7.5 |
| CVE-2026-64578 | ksmbd: validate compound request size before reading StructureSize2 | 8.2 |
| CVE-2026-64579 | xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert | no score |
| CVE-2026-64580 | xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() | 7.8 |
| CVE-2026-64581 | xfrm: fix sk_dst_cache double-free in xfrm_user_policy() | 7.8 |
| CVE-2026-68289 | tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() | no score |
| CVE-2026-68290 | rds: tcp: unregister sysctl before tearing down listen socket | 7.8 |
| CVE-2026-68297 | tipc: fix u16 MTU truncation in media and bearer MTU validation | 7.8 |
| CVE-2026-68315 | sctp: validate stream count in sctp_process_strreset_inreq() | 7.5 |
| CVE-2026-74544 | net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds | 7.8 |
| CVE-2026-74561 | nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush | 8.8 |
| CVE-2026-74562 | nexthop: take nh->lock for f6i_list walks in replace check and notify | 8.8 |
| CVE-2026-74579 | netfilter: nft_payload: fix mask build for partial field offload | 7.1 |
| CVE-2026-74701 | net/openvswitch: check Ethernet header length in key_extract() | 7.8 |
| CVE-2026-74710 | xsk: require at least 16 bytes of TX metadata | 7.8 |
| CVE-2026-74726 | bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor | 7.3 |
| CVE-2026-74748 | netfilter: ipset: fix refcount race between list:set GC and swap | 7.8 |
| CVE-2026-89788 | ksmbd: fix tree connection use-after-free in smb2_tree_connect() | 9.8 |
| CVE-2026-89789 | gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free | 7.8 |
| CVE-2026-89790 | ipv6: avoid divide by zero in rt6_multipath_rebalance | no score |
| CVE-2026-90115 | xsk: fix NULL pointer dereference in __xsk_rcv() | no score |
| CVE-2026-97938 | reboot: fix cad_pid use-after-free race | no score |
| CVE-2026-98222 | KEYS: encrypted: fix integer overflow of datablob_len | no score |
| CVE-2026-98364 | xfrm: hold net_device reference under RCU in bundle creation | 7.8 |
| CVE-2026-98384 | bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() | no score |
| CVE-2026-98810 | wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() | no score |
| CVE-2026-98968 | amt: send the relay's General Query directly from the receive path | 8.1 |
| CVE-2026-99138 | tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO) | no score |
| CVE-2026-99139 | tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) | no score |
The question the post leaves open
The lab ends by asking whether a system is secure even after every bug found has been fixed. The sharper question sits in its own funnel: when a vendor quotes a bug count, which of the stages in that funnel is the number counting, and how many hours of the people who must fix the bugs does it assume?
Key facts
Sources
- PrimaryLessons from 59 Linux Kernel Bug Reports, 11 November 2026: the funnel counts, models, token shares, outcomes and the eight exploit table. Read in fullMicrosoft Security Blog (FORGE Lab)accessed 2026-11-11
- PrimaryThe lab's own copy of the post, 11 November 2026, with the SVG figures that print token totals and bin counts. Read in fullMicrosoft FORGE Lab blogaccessed 2026-11-11
- Primarycves.txt: the lab's list of 33 CVE ids, read from the repository page's embedded file dataMicrosoft FORGE Lab (microsoft/forge-lab on GitHub)accessed 2026-11-11
- PrimaryFigure 1 as an SVG: counts, token totals, models and the description with the 10,842 figure. Read in fullMicrosoft FORGE Lab blogaccessed 2026-11-11
- PrimaryFigure 2 as an SVG: mean, median and the seven age bins. Read in fullMicrosoft FORGE Lab blogaccessed 2026-11-11
- PrimaryCVE.org record for CVE-2026-64563 (rhashtable): score, changed files and dates. One of 33 records read in fullCVE Program (Linux kernel CNA)accessed 2026-11-11
- PrimaryCVE.org record for CVE-2026-89788 (ksmbd), the only Critical score among the 33. One of 33 records read in fullCVE Program (Linux kernel CNA)accessed 2026-11-11
- PrimaryCVE.org record for CVE-2026-98222 (security/keys), which carried no score. One of 33 records read in fullCVE Program (Linux kernel CNA)accessed 2026-11-11
- PrimaryCVE.org record for CVE-2026-74561 (nexthop), whose scoring rationale names Microsoft. One of 33 records read in fullCVE Program (Linux kernel CNA)accessed 2026-11-11
- PrimaryKnown Exploited Vulnerabilities catalogue, release 2026.11.10 (1,779 entries): none of the 33 ids listedCISAaccessed 2026-11-11
- PrimaryA thousand fewer paths to root, 4 November 2026: used only for the comparison table. Read in the copy saved by the lead on 5 November 2026OpenAIaccessed 2026-11-05
