Description
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.
Published: 2026-09-16
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Privilege Escalation / Remote Code Execution
Action: Patch
AI Analysis

Impact

A flaw in the Linux kernel’s DAMON mt a use‑after‑free when stopping DAMON contexts. The stop routine assumes all contexts halt successfully and deallocates memory for stopped contexts. If a context is already stopped, the routine fails for that one, leaving other contexts running; subsequent deallocation frees memory still in use by the running context, creating a use‑after‑free that an attacker could exploit to execute arbitrary code in kernel mode. The weakness is a classic use‑after‑free condition.

Affected Systems

This vulnerability is present in the core Linux kernel. No specific version numbers are listed, so any kernel revision that has not yet incorporated the fix is potentially affected.

Risk and Exploitability

The CVSS and exploitation probability are not quantified, but the EPSS score is reported as less than 1 % and the flaw is not listed in the CISA KEV catalog, indicating a low public exploit likelihood. However, because the issue involves kernel memory, exploitation would require a local attack that can influence the DAMON module, leading to privilege escalation or remote code execution if the attacker can control the stopping process. The precise attack vector would involve manipulating DAMON contexts or induced allocation failures in kdamond_fn().

Generated by OpenCVE AI on September 18, 2026 at 00:21 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the DAMON mtier stop routine fix.
  • If an update is not yet available, consider disabling the DAMON module or preventing execution of DAMON contexts until the issue is patched.
  • Verify that damage from use‑after‑free no longer occurs by inspecting kernel logs for related errors after disabling DAMON or applying the patch.

Generated by OpenCVE AI on September 18, 2026 at 00:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 00:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description 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.
Title samples/damon/mtier: handle damon_stop() failure
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T10:33:15.423Z

Reserved: 2026-09-11T19:38:34.781Z

Link: CVE-2026-90006

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:13.213

Modified: 2026-09-16T11:17:13.213

Link: CVE-2026-90006

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T00:30:16Z

Weaknesses