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

What is CVE-2026-46025?

CVE-2026-46025 is a medium-severity vulnerability in Linux kernel, published on 27 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official 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].

Weakness: CWE-362

Which versions are affected by CVE-2026-46025?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2026-46025?

Apply the vendor's patch.

Is CVE-2026-46025 being exploited?

There is no known exploitation of CVE-2026-46025 in the wild and no public exploit code.

Other vulnerabilities in Linux kernel

• CVE-2026-53266 Linux Kernel Out-of-Bounds Write Exploited High 8.8
• CVE-2013-6282 Linux Kernel Improper Input Validation Exploited High 8.8
• CVE-2022-0185 Linux Kernel Heap-Based Buffer Overflow Exploited High 8.4
• CVE-2013-2094 Linux Kernel Privilege Escalation Exploited High 8.4
• CVE-2026-53362 Linux Kernel Unspecified Exploited High 7.8

All Linux kernel vulnerabilities

Sources

• CVE record
• NVD
• OSV
• GitHub advisory
• How this page is made

Also known as BELL-CVE-2026-46025, DEBIAN-CVE-2026-46025, GHSA-rhpm-rxf4-q3hf, UBUNTU-CVE-2026-46025.