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

mm/damon/core: fix damon_call() vs kdamond_fn() exit race

Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit
race".

damon_call() and damos_walk() can leak memory and/or deadlock when they
race with kdamond terminations. Fix those.


This patch (of 2);

When kdamond_fn() main loop is finished, the function cancels all
remaining damon_call() requests and unset the damon_ctx->kdamond so that
API callers and API functions themselves can know the context is
terminated. damon_call() adds the caller's request to the queue first.
After that, it shows if the kdamond of the damon_ctx is still running
(damon_ctx->kdamond is set). Only if the kdamond is running, damon_call()
starts waiting for the kdamond's handling of the newly added request.

The damon_call() requests registration and damon_ctx->kdamond unset are
protected by different mutexes, though. Hence, damon_call() could race
with damon_ctx->kdamond unset, and result in deadlocks.

For example, let's suppose kdamond successfully finished the damon_call()
requests cancelling. Right after that, damon_call() is called for the
context. It registers the new request, and shows the context is still
running, because damon_ctx->kdamond unset is not yet done. Hence the
damon_call() caller starts waiting for the handling of the request.
However, the kdamond is already on the termination steps, so it never
handles the new request. As a result, the damon_call() caller threads
infinitely waits.

Fix this by introducing another damon_ctx field, namely
call_controls_obsolete. It is protected by the
damon_ctx->call_controls_lock, which protects damon_call() requests
registration. Initialize (unset) it in kdamond_fn() before letting
damon_start() returns and set it just before the cancelling of remaining
damon_call() requests is executed. damon_call() reads the obsolete field
under the lock and avoids adding a new request.

After this change, only requests that are guaranteed to be handled or
cancelled are registered. Hence the after-registration DAMON context
termination check is no longer needed. Remove it together.

Note that the deadlock will not happen when damon_call() is called for
repeat mode request. In tis case, damon_call() returns instead of waiting
for the handling when the request registration succeeds and it shows the
kdamond is running. However, if the request also has dealloc_on_cancel,
the request memory would be leaked.

The issue is found by sashiko [1].
Published: 2026-05-27
Score: 4.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability is a race condition (CWE‑362, CWE‑366) that can cause damon_call() to wait indefinitely or to leak memory when kdamond is terminating. The bug arises because damon_call() registers a request while a separate mutex updates the damon_ctx->kdamond flag, allowing damon_call() to believe the kdamond thread is still running and to wait for its handling, even though the thread is already on the path to exit. This mismatch can lead to a deadlock or memory exhaustion in the kernel.

Affected Systems

Linux kernel images that have not incorporated the patches referenced (commits 2691332, 55da816, e6a053a6) are vulnerable. All distributions shipping kernels prior to those commits may be at risk, as the CNA currently lists Linux as the affected vendor with no specific version range provided.

Risk and Exploitability

The CVSS score of 4.7 indicates moderate severity, while the EPSS score of less than 1% suggests a very low likelihood of exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation would require privileged kernel access and a scenario in which damon_call() is invoked concurrently with kdamond termination, such as during system shutdown or composite device operations. If triggered, the kernel could become unresponsive or lose memory resources, effectively causing a denial of service.

Generated by OpenCVE AI on June 18, 2026 at 03:59 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a release that includes the damon_call and damos_walk race condition fix, using the commit identifiers provided in the advisories.
  • If an immediate kernel upgrade is not possible, locate and modify any code paths that call damon_call() during system shutdown or when kdamond may be terminating so that new requests are not queued until after the thread has finished.
  • As a temporary workaround, adjust system shutdown scripts or composite device management services to delay or suppress damon_call-related operations until kdamond has completed its termination sequence.

Generated by OpenCVE AI on June 18, 2026 at 03:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-8488-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8489-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8488-2 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8507-1 Linux kernel (NVIDIA) vulnerabilities
History

Tue, 16 Jun 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
Metrics cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}


Thu, 28 May 2026 00:15:00 +0000


Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix damon_call() vs kdamond_fn() exit race Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit race". damon_call() and damos_walk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those. This patch (of 2); When kdamond_fn() main loop is finished, the function cancels all remaining damon_call() requests and unset the damon_ctx->kdamond so that API callers and API functions themselves can know the context is terminated. damon_call() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damon_call() starts waiting for the kdamond's handling of the newly added request. The damon_call() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damon_call() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damon_call() requests cancelling. Right after that, damon_call() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damon_call() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damon_call() caller threads infinitely waits. Fix this by introducing another damon_ctx field, namely call_controls_obsolete. It is protected by the damon_ctx->call_controls_lock, which protects damon_call() requests registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of remaining damon_call() requests is executed. damon_call() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. Note that the deadlock will not happen when damon_call() is called for repeat mode request. In tis case, damon_call() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloc_on_cancel, the request memory would be leaked. The issue is found by sashiko [1].
Title mm/damon/core: fix damon_call() vs kdamond_fn() exit race
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-06-14T17:48:48.849Z

Reserved: 2026-05-13T15:03:33.093Z

Link: CVE-2026-46025

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-27T14:17:21.013

Modified: 2026-06-17T10:52:55.270

Link: CVE-2026-46025

cve-icon Redhat

Severity :

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-46025 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-18T04:00:15Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-366

    Race Condition within a Thread