CVE-2026-90006

UNRATEDCVSS · not yet scoredTrending — 3 sources updated this week
—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: None knownExposed services: Not assessed

No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.

In the Linux kernel, the following vulnerability has been resolved:

samples/damon/mtier: handle damon_stop() failure

damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context.

Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier.

For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later.

The issue was discovered [1] by Sashiko.

CVSS v3
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
0.2%
EPSS %ILE
11th
KEV
Not listed

Published

September 16, 2026

Last Modified

September 16, 2026

Vendor Advisories for CVE-2026-90006(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
Debian:14(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (178 versions)
  • every version up to 7.2.6-1: fixed in 7.2.6-1
—

Data Freshness Timeline

(refreshed 8× in last 7d / 25× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-10-04 23:22 UTCEPSS rescore
  2. 2026-10-02 22:39 UTCGHSA enrichment
  3. 2026-10-01 19:51 UTCEPSS rescore
  4. 2026-09-30 15:04 UTCEPSS rescore
  5. 2026-09-30 04:45 UTCEG score recompute
  6. 2026-09-30 04:45 UTCGHSA enrichment
  7. 2026-09-28 13:52 UTCEPSS rescore
  8. 2026-09-28 13:52 UTCEPSS rescore
  9. 2026-09-27 13:49 UTCEPSS rescore
  10. 2026-09-27 10:49 UTCGHSA enrichment
  11. 2026-09-26 15:59 UTCEPSS rescore
  12. 2026-09-24 16:57 UTCGHSA enrichment
  13. 2026-09-24 14:04 UTCEPSS rescore
  14. 2026-09-23 17:54 UTCEPSS rescore
  15. 2026-09-22 16:01 UTCEPSS rescore
  16. 2026-09-21 23:05 UTCGHSA enrichment
  17. 2026-09-21 21:09 UTCEPSS rescore
  18. 2026-09-20 20:16 UTCEPSS rescore
  19. 2026-09-19 05:13 UTCEG score recompute
  20. 2026-09-19 05:13 UTCGHSA enrichment
  21. 2026-09-18 19:28 UTCEPSS rescore
  22. 2026-09-17 19:32 UTCEPSS rescore
  23. 2026-09-16 11:21 UTCNVD update
  24. 2026-09-16 10:37 UTCEG score recompute
  25. 2026-09-16 10:36 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-90006?
CVE-2026-90006 is a publicly disclosed vulnerability published on September 16, 2026. In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damonsamplemtierstop() assumes its damonstop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call.…
When was CVE-2026-90006 disclosed?
CVE-2026-90006 was first published on September 16, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-90006 actively exploited?
CVE-2026-90006 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.2% probability of exploitation in the next 30 days (11th percentile of EPSS-scored CVEs).
How do I remediate CVE-2026-90006?
No fix for CVE-2026-90006 is confirmed yet. Until one is published, restrict network exposure of the affected system or apply the vendor's mitigation — for example, keep it off the internet or limit it to trusted networks — and watch the vendor's advisory for the fix. The vendor advisories EchelonGraph has for CVE-2026-90006 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-90006

Explore →

Is Your Infrastructure Affected by CVE-2026-90006?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.