CVE-2026-46025

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