PT-2026-43892 · Linux · Linux

Sashiko

·

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-46025

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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].

Related Identifiers

CVE-2026-46025

Affected Products

Linux