CVE-2026-46008
Analyzed Analyzed - Analysis Complete
Race Condition in Linux Kernel DAMON Core

Publication date: 2026-05-27

Last updated on: 2026-06-16

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix damos_walk() vs kdamond_fn() exit race When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() 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, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() 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 damos_walk() 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 damos_walk() caller thread infinitely waits. Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() 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. The issue is found by sashiko [1].
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-06-16
Generated
2026-06-16
AI Q&A
2026-05-27
EPSS Evaluated
2026-06-15
NVD
CVE-2026-46008
EUVD
EUVD-2026-32305
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 6.14 (inc) to 7.0.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's memory management subsystem, specifically in the interaction between the functions damos_walk() and kdamond_fn() within the DAMON (Data Access MONitor) context.

The problem arises because damos_walk() registers requests and checks if the monitoring daemon (kdamond) is still running by inspecting a shared context field (damon_ctx->kdamond). However, these operations are protected by different mutexes, leading to a race condition.

In certain timing scenarios, damos_walk() may add a new request and believe the daemon is still running, causing it to wait indefinitely for the request to be handled. Meanwhile, kdamond is actually terminating and will never process this new request, resulting in a deadlock where the caller thread waits forever.

The fix introduces a new field (walk_control_obsolete) protected by a dedicated lock to ensure that no new requests are added once the daemon is terminating, preventing the race and infinite wait.

Impact Analysis

This vulnerability can cause deadlocks in the Linux kernel's DAMON subsystem, where threads calling damos_walk() may wait indefinitely due to the race condition with the termination of the monitoring daemon.

Such deadlocks can lead to system instability or degraded performance, as kernel threads become stuck waiting for events that will never occur.

If your system relies on DAMON for memory access monitoring or related kernel features, this could impact the reliability and responsiveness of those components.

Mitigation Strategies

This vulnerability is resolved by a fix in the Linux kernel's mm/damon/core component that prevents a deadlock caused by a race condition between damos_walk() and kdamond_fn() exit.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46008. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart