CVE-2026-72178: mm/damon/core: always put unsuccessfully committed target pids

Published Aug 15, 2026
·
Updated

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

mm/damon/core: always put unsuccessfully committed target pids

damoncommittarget() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damondestroyctx() after damoncommitctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanuptarget() callback will put the pids.

The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damoncommitctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice.

The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanuptarget() ops callback, so it cannot put the pids via the damondestroyctx().

As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damoncommittarget() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions.

Fix by putting the pids in the commit operation in case of the failures.

The issue was discovered [2] by Sashiko.

Affected Software

1 affected component
Linux Kernel Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Apply the fix in mm/damon/core to ensure that if damon_commit_target() fails (e.g., due to memory allocation failure during context/target commit), the target PIDs that were unsuccessfully committed are still put/released (so they are not leaked).

    Linux kernel mm/damon/core put unsuccessfully committed target pids (on damon_commit_target/ctx failure paths) = enabled

Event History

Aug 15, 2026
CVE Published
via MITRE·05:53 AM
Data Sourced
via MITRE·05:53 AM
Description
Data Sourced
via NVD·06:21 AM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-72178?

CVE-2026-72178 has a risk score of 15, indicating a high severity vulnerability.

2

How do I fix CVE-2026-72178?

To remediate CVE-2026-72178, update your Linux kernel to the latest patched version as recommended by the maintainers.

3

What systems are affected by CVE-2026-72178?

CVE-2026-72178 affects the Linux kernel versions that include the mm/damon/core functionality.

4

What is the impact of CVE-2026-72178?

The vulnerability can potentially lead to resource management issues within the kernel, impacting system stability.

5

Is CVE-2026-72178 being actively exploited?

As of now, there have been no confirmed active exploits targeting CVE-2026-72178.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203