CVE-2026-46025: mm/damon/core: fix damon_call() vs kdamond_fn() exit race

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

mm/damon/core: fix damoncall() vs kdamondfn() exit race

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

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

This patch (of 2);

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

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

For example, let's suppose kdamond successfully finished the damoncall() requests cancelling. Right after that, damoncall() is called for the context. It registers the new request, and shows the context is still running, because damonctx->kdamond unset is not yet done. Hence the damoncall() 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 damoncall() caller threads infinitely waits.

Fix this by introducing another damonctx field, namely callcontrolsobsolete. It is protected by the damonctx->callcontrolslock, which protects damoncall() requests registration. Initialize (unset) it in kdamondfn() before letting damonstart() returns and set it just before the cancelling of remaining damoncall() requests is executed. damoncall() 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 damoncall() is called for repeat mode request. In tis case, damoncall() 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 dealloconcancel, the request memory would be leaked.

The issue is found by sashiko [1].