CVE-2026-46025: Linux Kernel Race Condition Vulnerability

CVE-2026-46025 Overview

CVE-2026-46025 is a race condition in the Linux kernel's Data Access MONitor (DAMON) subsystem. The flaw resides in mm/damon/core and affects the interaction between damon_call() and kdamond_fn() during context termination. When these functions race, callers can experience indefinite waits or memory leaks tied to requests that include dealloc_on_cancel.

The root issue is that request registration and the damon_ctx->kdamond unset operation are guarded by different mutexes. A caller can register a request after kdamond_fn() has already cancelled pending requests but before it clears the running indicator, leaving the request unhandled.

Critical Impact
Threads invoking damon_call() can block indefinitely, and requests with dealloc_on_cancel set can leak memory when racing with kdamond termination.

Affected Products

Linux kernel versions containing the DAMON damon_call() and damos_walk() interfaces in mm/damon/core
Distributions shipping affected upstream stable kernels prior to the referenced fix commits
Workloads using DAMON-based memory access monitoring or DAMOS schemes

Discovery Timeline

2026-05-27 - CVE-2026-46025 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46025

Vulnerability Analysis

The vulnerability is a race condition [TOCTOU-style] between damon_call() request registration and kdamond_fn() termination. damon_call() first adds the caller's request to a queue, then checks whether damon_ctx->kdamond is still set to decide whether to wait for handling. If the kdamond thread is still flagged as running, the caller blocks on completion of its request.

Because request registration and the clearing of damon_ctx->kdamond are protected by separate mutexes, the registration can interleave with kdamond's shutdown path. If kdamond_fn() has already executed its cancellation pass over pending requests but has not yet cleared the running flag, a newly registered request never gets handled.

The caller observes a running kdamond and waits forever. For repeat-mode requests, damon_call() returns without waiting, so the deadlock does not occur — however, when such a request carries dealloc_on_cancel, its memory is leaked because the cancellation pass already completed.

Root Cause

The defect stems from inconsistent locking around two related state transitions. The patch introduces a new call_controls_obsolete field in damon_ctx, protected by damon_ctx->call_controls_lock — the same mutex that guards request registration. kdamond_fn() initializes the field before damon_start() returns and sets it just before cancelling remaining damon_call() requests.

Attack Vector

Exploitation requires local access and the ability to invoke DAMON interfaces concurrently with kdamond lifecycle events. The race was discovered using the sashiko fuzzing tool. The practical impact is local denial of service through thread hangs and kernel memory exhaustion via leaked request structures.

The vulnerability manifests when timing aligns the damon_call() registration window with the narrow interval between kdamond's request cancellation pass and its clearing of the context pointer. See the upstream commits referenced below for the exact code paths and ordering.

Detection Methods for CVE-2026-46025

Indicators of Compromise

Tasks stuck in uninterruptible sleep (D state) waiting on DAMON request completion within kernel stack traces referencing damon_call or damos_walk.
Growth in unreclaimable kernel slab allocations associated with DAMON request structures over the lifetime of monitored workloads.
Hung task warnings emitted by khungtaskd referencing threads blocked on DAMON contexts after kdamond termination.

Detection Strategies

Audit running kernels against the fix commits 2691332, 55da816, and e6a053a to confirm presence of the call_controls_obsolete field.
Correlate process hangs with DAMON sysfs activity, including starts and stops of monitoring contexts.
Monitor for repeated DAMON context create/destroy cycles from unprivileged or sandboxed workloads that have access to DAMON sysfs interfaces.

Monitoring Recommendations

Enable kernel CONFIG_DETECT_HUNG_TASK and forward khungtaskd warnings to centralized logging.
Track kernel memory usage trends with slabtop or /proc/slabinfo to surface gradual leaks tied to DAMON request objects.
Alert on processes interacting with /sys/kernel/mm/damon/ that exhibit thread stalls or rising kernel-side memory accounting.

How to Mitigate CVE-2026-46025

Immediate Actions Required

Apply the upstream stable kernel updates that include the fix commits referenced in the NVD entry.
Restrict access to DAMON sysfs interfaces to trusted administrative users only.
Disable DAMON (CONFIG_DAMON) in builds where the subsystem is not required.

Patch Information

The fix is delivered via three upstream commits that introduce the call_controls_obsolete field and adjust the registration path. See Kernel Git Commit Patch 2691332, Kernel Git Commit Patch 55da816, and Kernel Git Commit Patch e6a053a. After registration, the new field gates whether requests are accepted, so only requests guaranteed to be handled or cancelled are queued.

Workarounds

Avoid programmatic patterns that create and destroy DAMON contexts in rapid succession while issuing damon_call() requests.
Remove dealloc_on_cancel semantics from custom DAMON consumers until the kernel is patched, accepting the trade-off of manual cleanup.
Use mandatory access control (SELinux, AppArmor) policies to deny non-administrative workloads access to DAMON sysfs nodes.

bash

# Restrict DAMON sysfs access to root only
chmod -R o-rwx /sys/kernel/mm/damon/
chmod -R g-rwx /sys/kernel/mm/damon/

# Verify running kernel version matches a patched stable release
uname -r